November 29, 20232 yr So for a while a lot of my SMB files were changing owner to the SMB user I was using to log into SMB Unraid through Windows. I added some lines to the SMB config file that forces the default user to "nobody:nogroup" I'm using this and it works fine defaulting it to nobody:nogroup [share] path = /mnt/user/share public = no browseable = no guest ok = no writeable = yes read only = no force user = nobody force group = nogroup create mask = 0640 directory mask = 0750 #Show ZFS Snapshots vfs objects = shadow_copy2 shadow: snapdir = .zfs/snapshot shadow: sort = desc shadow: format = autosnap_%Y-%m-%d_%H:%M:%S_daily shadow: localtime = yes However, I think it would probably be better if I had it inherit the user from the root folder instead, as I have some more restricted folders setup. But this doesn't work as expected. Removing "force user" "force group" and then adding this has no effect: inherit permissions = yes Is there a better way of accomplishing this? Edited November 29, 20232 yr by samsausages
November 29, 20232 yr Community Expert I don't know where you got the idea this was a ideal setup for SMB. (I want to caution anyone who reads this post, you are on your own if you use this as a pattern for how to configure SMB on Unraid!!) First, The default owner should be nobody for a directory of file. The group should always be users Now for the reason behind this choice. First, the owner, nobody, is assigned when a 'guest' is permitted on the system because a share has the permission set to "Public". If you set the permission on a share to either "Secure" or "Private", the owner of any new file (or directory) becomes the Share User who has write permissions on the Share. (Note: that multiple Share Users can have write permissions to a Share so this means there can be multiple Share Users who are owners of various files and directories in the share! (If you have a Docker of VM that writes directly using Linux to a share, you want to make sure that it does so as nobody-users.) How is this issue resolved? The answer is that Share Users are member of the group--- users. (This includes the default nobody.) Now, let's see what is really going on. There are two levels of access to files via SMB. The top layer is SMB and you set those permissions in the Shares settings in GUI. If the share permission is either "Secure" or Public", you set the access privileges of each of the defined Share Users-- 'No Access', 'Read only', or 'Read/Write'. The SMB analyses each request from a client and passes any request for permitted file access for the user requesting it onto the underlying Linux file system. (Obviously, if the Share User requests an action which is not permitted, it is not pass on!) Now the Linux file system gets the request. This request is handled using the Linux file rules! First, it checks to see if requester is the owner. If so, the request is process using the owner's permissions. If the requestor is not, the owner, Linux checks to see if the requester is a member of the 'group'. If so, the request is processed using the 'group' permissions. Now, take a deep breath. Remember, Unraid assigns all Share Users to the users group. (Yes, there are ways to change the group name and there is probably a way to create another group but you would have to dig deep in Linux to do so.) If I want two Share Users to be able to have Read/Write access to every file in a share regardless of which users created that share, the permission on group have to (at least) -rw-rw---- (or 660 for files). For directories, it has to be -rwxrwx--- (or 770) (Unraid has default this to 666 and 777 and it has been this way for several years now.) Basically, for Unraid SMB to be able to able to function correctly requires that the group has the same permissions as the owner! Now, you may be asking some questions. One of these might be-- What if I have multiple Share Users on my Unraid server and they are all members of the users group (at the Linux level), how so I prevent them from access a share that I don't want them to have access to. The answer is simple. You make sure they are assigned to have 'No access' permission at the 'SMB user access' settings in the Share settings for that share in GUI. That way those users requests are never passed down to Linux File system for processing. Edited November 29, 20232 yr by Frank1940
December 9, 20232 yr Quote First, The default owner should be nobody for a directory of file. The group should always be users Why does Unraid then default all files written by me through SMB as "myname:users" and not "nobody:users"? I've googled for hours and find endless posts with people having issues, but don't seem to see a single post anywhere on what is "the best way to approach unraid+SMB" and 2) how to implement this best approach. You seem to have some insights. Would you have any pointers?
December 9, 20232 yr Community Expert In the recent versions of Unraid, if you have logged into SMB using credentials, the files' owner will be that of the Share User who wrote them. This does not make any difference to how SMB works if the permissions on group, 'users', are correct. This is because valid Share Access Users are members of the group-- 'users'. (This assumes that the permissions for the group ('users') are rw- for files and rwx for directories.) The only fly in this ointment is a Docker or VM writes a file with the group file permission being r-- (This has been the source of several permissions issues lately!) If you (or anyone else reading this post) have a problem with the group permissions not being correct, look and see if the UMASK in the Docker is set to 000 [or in some cases 0000].) You may find that Dockers or VM's may being using nobody:users or if a share is set to Public and some user has managed to get 'guest' privileges to an Unraid server, any files that they save will have a owner of nobody. I have not found any issue with the owner of either files or directories not being 'nobody' in causing any problems in SMB. The 'New Permissions' tool will fix the owner not being 'nobody' but as long as it a valid Share Access User BUT this step should not be required. (Unless something else is screwed up!) ============= Let me now state this a slightly different way. Realize that there are two layers of permissions to access a file (or directory) using SMB. The top layer In Unraid is Samba and the next layer down is the Linux file system. Every SMB completed operation will be processed by both layers and permission to a resource can be denied by either level! If a file is owned by 'Husband' and the user 'Wife' needs access to the file, let's look at what is going to be happening. First thing is that the Samba Security Settings for that Share must be setup to permit them access to the share. Next, if the share is either 'Secure' or 'Private', both Husband and Wife must be granted access to the share. If Wife does not have access permission, Samba blocks them at this point and the Linux file permissions are a moot point. If they only have read-only permission and they request a operation that requires a write, Samba, again, will block them and Linux file permissions again are a moot point. If Samba determines that the request is valid, it passes the request down the Linux file level. Now those Linux file permissions come into play. First Linux checks if the requester is the owner of the file. If it is, the access would be granted based on the owner permissions. In our case, Wife is not the owner. Then Linux will check to see if the requestor, Wife, is a member of the group. (Because of the way, LimeTech has set things up, Wife will be a member of the group, 'users'.) Thus, Wife has granted access via the group permissions. ========== Hope this helps...
December 17, 20232 yr Author On 11/29/2023 at 3:57 PM, Frank1940 said: I don't know where you got the idea this was a ideal setup for SMB. (I want to caution anyone who reads this post, you are on your own if you use this as a pattern for how to configure SMB on Unraid!!) I manage file permissions at the linux level, that is my intention for my use case. I don't always want the SMB user to be the owner of the file. I also don't run all my containers with 99:100, sometimes I use masking, sometimes I don't, depends on what I'm doing.. I'm not telling other people to do what I'm doing... I'm asking what others are doing so I can get ideas for my use case. Edited December 17, 20232 yr by samsausages
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.