Hopefully someone can help as this is driving me mad.
I have created a number of datasets and I have three basic levels of access for each depending on which group the user has been added to.
Group 1 - Read Only (Self Explanatory).
Group 2 - Read/Write/Append (Users can read and create new or append files, but not delete anything).
Group 3 - Modify (Users can read, write and delete files and folders).
The problem I’m having is that when a new file or folder is created, the owner of the file is set to the user who created it, not ‘root’ as is desired.
I’ve tried everything but I can’t seem to get newly created files/directories to inherit the root owner instead of the end-user. This means that even if I’m only a member of ‘Group 2’ I can still delete files/folders that I copied to the share.
I’ve created the appropriate groups/ACLs without the delete permission, but it doesn’t apply if you’re the owner of the file since the owner overrides that permission.
Tried that. I removed the owner@ ACL but for some strange reason, the owner can still delete files/folders that they created/copied to the server. (I made sure to apply the ACL recursively.) I can’t see anywhere obvious why this would be the case.
The permissions appear to work correctly via SFTP, but not via SMB.
I think I worked it out. I added the following additional parameters to the SMB share options:
inherit owner = yes inherit permissions = yes
For some reason, inherit owner alone won’t work. Now, when I create files or folders via SMB, the ACLs are applied properly. I can create but not rename or delete items.
If I SSH into the FreeNAS server, all files/directories under that dataset automatically default to root/wheel as the owner.
The only caveat with this is if you’re adding/removing users from a group, you must stop/start the SMB service for the new “permissions” to take effect. It’s not ideal, but it works for me.
For those wondering why I’m doing it this way, it’s because a lot of the data on these datasets are “common” to many users. One physical person shouldn’t “own” the data, the system/company should. The only exception to this is the user’s own home folder.
Are you in a Windows environment? If so then using Windows files permissions are easy to deal with, and you can force through group policy tat administrators have access to user files. All of our student accounts are set up this way so that teachers can play the projects for grading. It also makes it easier when it is time to delete a student when they graduate. That said, these are still on 11.1 and I know the ACLs have changed a lot on the newer versions, something I need to dig into when I’m not trying to fit more students into a space that isn’t big enough due to distancing rules… This summer was supposed to let me catch up on a bunch of this stuff.
We mostly use Linux machines with a sprinkling of Windows. I’m aware you can use the Windows permissions to manage ACLs but since I only use Linux myself, it would be a pain to manage.
Interestingly, the Samba documentation actually includes this as a specific use-case in its documentation. It states:
The ownership of new files and directories is normally governed by effective uid of the connected user. This option allows the Samba administrator to specify that the ownership for new files and directories should be controlled by the ownership of the parent directory.
Common scenarios where this behavior is useful is in implementing drop-boxes, where users can create and edit files but not delete them and ensuring that newly created files in a user’s roaming profile directory are actually owned by the user.
To me, having the server manage this itself is preferable over dicking around with Windows permissions (where mistakes can be made due to human error). This way, I only need to set the ACLs in FreeNAS then add the user to the appropriate group.
EDIT: Having worked on this issue for a few days now, I can’t conclude that it’s working as it should… it’s only kinda-sorta working.
The above works only for files/folders in the root of a dataset, but don’t inherit properly into subfolders or files. This obviously creates a huge problem because those with write (but not delete) permissions can still delete files via SMB, even with an explicit deny ACL set recursively. I’ve been having some luck by setting dataset share types to “Generic” instead of “SMB” and ACL mode to “Passthrough” (even when used with SMB shares/clients). I’ll report back tomorrow with my findings.