After having trouble with one of my shares, I decided to review all of the permissions on all of my shares. I noticed that “Other” was set to allow Read and Execute. I didn’t know what (or who) “Other” might be, so I systematically went down the line and disabled all permissions for “Other” on each of my shares. When I disabled “Other” on my root share, the box crashed and has become totally inaccessible. The root share was already owned by root and in the root group, so why does “Other” need access? Is there a way to fix this without reinstalling? Any help is much appreciated.
The “other” (or “world”) are those users that neither own the file or directory nor are members of its group. Unfortunately, /mnt2/root does not have anything to do with the root user (unlike /root), but is a btrfs subvolume representing the root of the filesystem. This issue has been touched upon in the following post and related github issue:
The result is that a lot of the files on your filesystem now not only have the wrong permissions but are also owned by the wrong user/group. This is technically repairable through SSH if you have a reference system (e.g. a VM) with correct permissions. However, it will be a lot of work and you’re probably better off reinstalling.
2 Likes
That’s a super helpful reply. Now that I know, I’ll just clean install and won’t mess with that again.
For future reference, is there anything I need to do from default to lock down my share access permissions? I always have to go in and manually add users after creating them, so I assume the default settings allow nothing other than what is required. Is that correct?
So should I leave “other” allowed on all of my shares, or just the root share?
You mean in Samba settings?
It depends on what kind of access you want to allow. The default permissions are 755 (rwxr-xr-x) for directories and 644 (rw-r--r--) for regular files. This makes sense for the system files, mostly owned by root, because this way every user and the software they run can use but not modify them. Only some very sensitive files and directories have group/other access disabled.
But for non-system stuff like file sharing, you can regulate access however you want. I have some generic public shares set up with permissions rwxrwxr-x and they are owned by root:share_access. The corresponding Samba exports are set to be browsable and writable, but no guest access. This way I have specified that:
- Only users with a system account can access these shares, and
- Only those users I add to the share_access group are allowed write access.
On the other hand, for a share that is private to just one user, you can be extremely strict and set the ownership to just that user and permissions to rwx------.
Anything between completely private and completely public is possible and you can achieve file, user and group specific granularity of permissions by combining system permissions and the plethora of Samba options.
Fantastic! At least it seems like I’ve been doing those steps correctly. To be clear, I usually add all of our home users to the “users” group. I then leave root at the owner of all the shares, move them to the users group, and give full permissions to both owner and group, while removing all permissions for other. That seems to have been an acceptable way to secure the shares based on what you’ve said above. If I want to parcel out shares individually in the future, I can do so by creating another group or by making that specific user the share’s owner. Pretty cool!
Thanks to your advice, I’m back up and running with a clean install. Kudos to Rockstor for being incredibly easy to reinstall and reconfigure. The whole process took maybe 30 minutes. It imported all of my shares/pools without any issue.
Excellent. Indeed you can restrict others’ permissions if you want, they are mostly useful if you want to have an additional level of unprivileged/guest access. I personally also use Samba’s [homes] shares and give each user directory permission 700, because I already have other shares where public files can be put.