SMB Permissions on Newly Created Files

[bemarino]

I'll open by admitting that this topic has confused and frustrated me so much that I would be prepared to pay for a one-off support call just to understand and fix it (unfortunately it looks like I need a standing support contract for that). So I'm going to try posting here.

I have a newly-built TrueNAS Scale server that is replacing an older TrueNAS Core server. I want to run SMB shares on my new server. No Active Directory or LDAP to worry about on the network. Just bog-standard SMB shares that two people need to access using credentials defined in "Local Users".

So I have the shares working, but the Unix file permissions that Samba sets on new file creation are making me rip my hair out. For starters, the ownership defaults to user:user when I need it to be user:sharegroup. The ONLY way I've found to fix this is to set "group = sharegroup" on each share's "Auxillary Parameters" section, which already is unintuitive and seems wrong. But literally NOTHING else I've tried has worked. It's either ignored or causes Samba to crash on startup if I try to set it in the global Samba config instead. And the "Edit ACLs" functionality has me beyond-confused and seems to have no effect regardless of what I try.

The other problem I'm having is that any new file's permissions are set to 775. This is annoying at best (and a security risk at worst). I want 664 so files aren't getting their Unix execute bit set. Before you tell me about "create mask", I've already tried it. It always either gets ignored, or both gets ignored and simultaneously causes "group = sharegroup" from above to ALSO get ignored. I have been completely unable to fix this masking problem no matter what I try.

I mention TrueNAS Core above because I've successfully used it since the FreeNAS 11.2 days. I've never experienced any of these behaviors over there. So I'm desperately hoping to understand just what the heck it is I'm doing wrong here, as NEITHER of these seemingly-default TrueNAS Scale behaviors seems remotely desirable for anybody (especially the group issue, which locks out the user that didn't create the file).

 

[anodos]

I'll open by admitting that this topic has confused and frustrated me so much that I would be prepared to pay for a one-off support call just to understand and fix it (unfortunately it looks like I need a standing support contract for that). So I'm going to try posting here.

I have a newly-built TrueNAS Scale server that is replacing an older TrueNAS Core server. I want to run SMB shares on my new server. No Active Directory or LDAP to worry about on the network. Just bog-standard SMB shares that two people need to access using credentials defined in "Local Users".

So I have the shares working, but the Unix file permissions that Samba sets on new file creation are making me rip my hair out. For starters, the ownership defaults to user:user when I need it to be user:sharegroup. The ONLY way I've found to fix this is to set "group = sharegroup" on each share's "Auxillary Parameters" section, which already is unintuitive and seems wrong. But literally NOTHING else I've tried has worked. It's either ignored or causes Samba to crash on startup if I try to set it in the global Samba config instead. And the "Edit ACLs" functionality has me beyond-confused and seems to have no effect regardless of what I try.

The other problem I'm having is that any new file's permissions are set to 775. This is annoying at best (and a security risk at worst). I want 664 so files aren't getting their Unix execute bit set. Before you tell me about "create mask", I've already tried it. It always either gets ignored, or both gets ignored and simultaneously causes "group = sharegroup" from above to ALSO get ignored. I have been completely unable to fix this masking problem no matter what I try.

I mention TrueNAS Core above because I've successfully used it since the FreeNAS 11.2 days. I've never experienced any of these behaviors over there. So I'm desperately hoping to understand just what the heck it is I'm doing wrong here, as NEITHER of these seemingly-default TrueNAS Scale behaviors seems remotely desirable for anybody (especially the group issue, which locks out the user that didn't create the file).

This is a difference between Linux and FreeBSD on new file creation. The steps to create an SMB share are as follows:
1) create user for share (make sure 'SMB') is checked
2) create dataset for share using 'SMB' preset (sharetype = SMB).
3) create SMB share pointing to new dataset's path (use defaults here)

Step (1) creates a user with an auxiliary group builtin_users
Step (2) creates a new dataset that grants builtin_users FULL_CONTROL

If you are experiencing actual Samba crashes, please PM me. So far I think all issues have been fixed for the upcoming 22.02.2 release.

The most common issue that users encounter permissions-wise is that they do something like this:
1) create dataset dozer/SHARES/SMB
2) change permissions of /mnt/dozer/SHARES to be something like 770 and owned by root:root.

Unfortunately this sort of advice was featured in at least one prominent youtube influencer video and totally breaks permissions for /mnt/dozer/SHARES/SMB because the permissions on /mnt/dozer/SHARES will prevent access for all users.

 

[bemarino]

This is what I finally did to get everything working like I wanted it:

1. Create dataset as normal. I left "Share Type" as Generic so we're dealing with Unix permissions only -- no extended ACLs.
2. Recursive chmod 2775 on all directories in the dataset, recursive chmod 664 on all files.
3. Recursive chgrp sharegroup on all directories in the dataset.
4. Create the SMB share with "No presets" and "Enable ACL" unchecked.
5. Use create mask = 0664 as the only auxiliary parameter on the SMB share.

The only downside I'm aware of with this setup is that it won't work in environments where you need to manage permissions via Windows. My environment is not one of those, so I'm fine with (and actually prefer) having ONLY the Unix file/folder permissions to make troubleshooting permissions issues significantly easier.

On a related note, I believe I may have stumbled on a bug where when you set more than a single "auxiliary parameter" on a share, all of them get ignored. My evidence is that EITHER "group = sharegroup" OR "create mask = 0664" will work by itself, but I could never set both options on the same SMB share (the chmod and chgrp from above eliminated the need for "group = sharegroup").

 

[anodos]

This is what I finally did to get everything working like I wanted it:

1. Create dataset as normal. I left "Share Type" as Generic so we're dealing with Unix permissions only -- no extended ACLs.
2. Recursive chmod 2775 on all directories in the dataset, recursive chmod 664 on all files.
3. Recursive chgrp sharegroup on all directories in the dataset.
4. Create the SMB share with "No presets" and "Enable ACL" unchecked.
5. Use create mask = 0664 as the only auxiliary parameter on the SMB share.

The only downside I'm aware of with this setup is that it won't work in environments where you need to manage permissions via Windows. My environment is not one of those, so I'm fine with (and actually prefer) having ONLY the Unix file/folder permissions to make troubleshooting permissions issues significantly easier.

On a related note, I believe I may have stumbled on a bug where when you set more than a single "auxiliary parameter" on a share, all of them get ignored. My evidence is that EITHER "group = sharegroup" OR "create mask = 0664" will work by itself, but I could never set both options on the same SMB share (the chmod and chgrp from above eliminated the need for "group = sharegroup").

Auxiliary parameters are newline-separated.

 

[fspolti]

What worked for me was:
1- enable filesystem ACL
2- create a common group for users that have full access
3- add all users to this group
4- check the box to set this default group for everything in the filesystem ACL

Hope that helps.
thanks