It would be very convenient if I could just set the Force User and Force Group SMB parameters. That way all files can be written as the same UID/GID I use to run OpenCloud and I wouldn’t have to use ACLs. My dataset is currently configured with ACL Type: Off to keep it simple.
I have 2 SMB shares, one for each user in my household. Share A is only accessible by user A, and Share B only by Share B. The files in these shares are mounted inside a docker container (OpenCloud). I’ve made an account for user A and B in OpenCloud as well. My users access their files via SMB and OpenCloud.
I’ve been using TrueNAS for some years and a previous version allowed me to create multiple users with the same UID/GID. I did this as a workaround, but this is starting to cause glitches in the WebUI. I prefer to create dedicated SMB users, but have their actions over SMB be forced to a specific owner/group.
Impact
Benefit: It allows to limit access SMB share access to specific TrueNAS users, while keeping the file ownership easily compatible with docker containers.
Since this is off by default I don’t see any downsides. I don’t require metadata about who created files. When users create files through OpenCloud it’s not possible to match it up with their SMB user ID. So this metadata is lost/mangled anyway.
User Story
While creating an SMB share, fill in the Force User and/or Force Group field. Default value is empty (disabled). Value could be a drop down with the users/groups created in TrueNAS.
This would be a major security hole in any environment using kerberos because it would allow any account in the environment (including AD machine accounts) to impersonate the user (basically anything that can get a kerberos ticket – not even a normal account). I don’t see us adding it personally. We support up to 1024 entries in an ACL. It’s not onerous to just add an additional group entry to owncloud.
If force user was combined with valid users, then only users (or groups) on the valid users list could connect to the share, then force user would force all of the allowed users to the given username.
Yeah, that’s an old / bad way of managing permissions. Samba’s an old project and has various approaches to managing permissions. This particular one is an avenue we didn’t pursue because it’s basically unsupportable at scale and runs counter to the established / functional workflow for NAS permissions.
If there was still the option “Auxiliary SMB parameters” available in the GUI, these parameters wouldn’t have the need to be “supportable”, but as it is now with the removal of “Auxiliary SMB parameters”, having the “Force User” and “Force Group” options in the GUI is less “optional” than you’d think
Thanks, but that is not possible in my case, we need to use SMB as we use this machine as an “intermediate” file server to be filled by really old operating systems - like WinXP (not too long ago there even was a WinNT machine) - to put their backups and other data, which can be transferred from there by rsync to a different (TrueNAS) server (that also doesn’t have to speak SMB1 and such). Unfortunately, we can’t touch the running client systems to install NFS clients or other stuff and have to set it up on the server, which is why that server still runs CORE until this is solved.
