Summary: I mistakenly changed the ownership of all files and directories to nobody:allaccount. I can't simply reinstall linux, because the OS is on a NAS, and I don't have access to the device specific version running on the NAS. I'm wondering if there's a simple, reliable way to export the ownership attributes from someone else's NAS of the same model and then transfer them to mine.

Long version:


I have a NAS that runs linux. At the command line, I entered the following command logged in as root by mistake:

I only wanted to change the ownership of the files in the current directory. I realized something was wrong when the command didn't finish instantly, so I terminated it. Unfortunately, the owner and group owner of many important system files and dirs was changed to nobody:allaccount before I aborted. Dirs whose ownership attributes were changed include: bin, /lost+found, /dev, /etc, /lib, /home and /mnt/web_page. Dirs whose ownership attributes are still root:root include: /proc, /usr, /sbin, /sys, /tmp and /var. Is the device unlikely to reboot if I restart it now? What other problems might I run into because of this?

Since I can't simply reinstall linux, I'm thinking I might be able to export the ownership attributes of important system files from a working NAS and import them to the corresponding files on my NAS. I don't have access to another NAS like mine locally (so I can't simply copy files over), but if there's a reliable script or software for this, I may be able to get someone to send me their permissions information in a text file.

Thanks for any help.

Boot processes that run before entering the first runlevel run as root but that's no guarantee there'll be no b0rkage.


If you didn't close your root session, or if you can access the file system as root in another way (like booting from a CDROM), then yes, you should be able to do that.

You could already run and fix any non-root assignments later on. To find assignments have somebody run as root on their NAS and send the plain text file to you. Inspect the contents before commencing as you will execute it. As root now run and you should see it apply ownership.

1 members found this post helpful.

Thanks so much for your help.

I may not actually find someone to send me a perms.log. In the meantime, is it safer to keep the /bin /lost+found /dev /etc /lib dirs with the current permissions (nobody:allaccount) or to change them to root:root? The device is on a secure network. I was thinking that more restrictive permissions (making everything root:root) might be worse than the very relaxed permissions I have now, in terms of the potential for device failure on boot or otherwise.

Edit: I think I'm conflating ownership and permissions. What I've written above would make more sense for permissions than it does for ownership. Rereading your post, I take it that processes owned by root:root have more privileges than processes owned by nobody:allaccount, and some processes might not be able to do what they need to do now that I've downgraded the associated files and dirs.

Edit 2: Would running the code you posted list all files in the dirs? If so, is there a chance someone who ran the code might inadvertently disclose private information (e.g., sensitive file names and sizes), or is it generally just system files that's stored in these dirs?

Understandable as you didn't mention brand name, type and any specs in your original post...


See for yourself: take another machine of yours, boot any Linux Live CD and check the permissions on the directories you mentioned.

1 members found this post helpful.

Thanks again, I really should load a Linux Live CD. I added a couple of edits to my last post. The device is a D-Link DNS-325 running firmware 1.02 (for the North America region).

Maybe post a request for your perms list in forums.dlink.com?

I'm trying to interpret the output of:

Instead of listing the owner and group owner by name, this command returns that information in some numerical form. On my device, there are only two ownership attribute pairs. Files and dirs in the output are listed in the following form - they're all owned by either 501:501 or 0:0:

I'm pretty sure 501:501 = root:root and 0:0 = nobody:allaccount on my device. But on someone else's device, I'm concerned that different numbers may be used for owners and owner groups. Is there a way I can modify the command to show the actual names of the owners and owner groups, instead of their codes?

Also, in the dirs I listed, is there a risk that someone may disclose sensitive information by uploading his perms.log for the dirs (to repeat them, the dirs are: /bin /lost+found /dev /etc /lib /home /mnt/web_page /proc /usr /sbin /sys /tmp /var).

It's the other way around: root has UID 0.


Its a standarized product and these are std account names so the root UID at least won't ever change.


Use lowercase so replacing the part with "%u:%g" should do.


That is a most excellent question. However using 'find' in the way I posted it it will be limited to mostly hardware device information, file names and obviously user names:
No:
/bin # std binaries
/lost+found # should not contain anything ever
/etc # std configuration files
/lib # std libraries
/sbin # std binaries
/proc # virtual file system contents show only process information (not traceable)
/sys # virtual file system contents reveal hardware device information (but not in a traceable way)

Maybe:
/mnt/web_page # maybe: dunno what the contents are
/usr # std binaries, libraries and other std contents. Maybe if users put stuff there they should not have

Yes:
/home # yes obviously
/dev # may reveal hardware device information including brand, type, serial and device labels ("pr0n", "my secret disk")
/tmp # may reveal file names if used as storage area
/var # std location for log files may reveal std process information but also file names if used as (temporary) storage area


Let's mitigate things the following way:
- change ownership recursively on /bin, /lost+found, /etc, /lib, /usr and /sbin recursively as root should own about anything anyway (and any wrong perms you'll get from the logs),
- change ownership on /sys, /proc and /dev as root should own about anything (and anything it doesn't will be recreated on reboot anyway),
- for each user name under /home change the second level directory name recursively to that users name and group,
- which should effectively leave you with just 'find /mnt/web_page /tmp /var -printf "chown %U:%G \"%p\"\n";'...

1 members found this post helpful.