Freenas 9.3 CIFS Inherit permissions

[monarchdodra]

When setting up a CIFS share prior to 9.3, I had the option to tick "inherit permissions". My 9.3 FreeNas does not give me this option anymore.

Furthermore, I noticed that when creating new files in a CIFS share, they are basicaly created with 777/666 permissions, regardless of the encompassing permissions.

How are we supposed to do permission inheritance in 9.3?

 

[anodos]

When setting up a CIFS share prior to 9.3, I had the option to tick "inherit permissions". My 9.3 free so does not give me this option anymore.

Furthermore, I noticed that when creating new files in a CIFS share, they are basicaly created with 777/666 permissions, regardless of the encompassing permissions.

How are we supposed to do permission inheritance in 9.3?

Set permissions the way you would on a windows server.
http://support.microsoft.com/en-us/kb/308419

 

[monarchdodra]

Hum. I guess I liked the old behavior better :/

 

[anodos]

Hum. I guess I liked the old behavior better :/

This does not represent a change in behavior at all. I have been managing permissions as I linked above since FreeNAS 9.2.1.x. The checkbox merely appended inherit permissions = yes to the smb4.conf file. You can do the same by adding an auxiliary parameter to your config, but it isn't recommended as it may break "windows" ACLs. The 9.2.1.x documentation states regarding this parameter

"if checked, the UNIX permissions on new files and directories are inherited from parent directory; this can be useful on large systems with many users as it allows a single homes share to be used flexibly by each user; do not check if Type of ACL is set to Windows in the Volume's permissions"

Likewise the samba documentation states:

inherit permissions (S)
The permissions on new files and directories are normally governed by create mask, directory mask, force create mode and force directory mode but the boolean inherit permissions parameter overrides this. New directories inherit the mode of the parent directory, including bits such as setgid. New files inherit their read/write bits from the parent directory. Their execute bits continue to be determined by map archive, map hidden and map system as usual. Note that the setuid bit is never set via inheritance (the code explicitly prohibits this). This can be particularly useful on large systems with many users, perhaps several thousand, to allow a single [homes] share to be used flexibly by each user.
Default: inherit permissions = no

 

[monarchdodra]

OK, but if my ACL is set to linux, then it should be fine, right?

 

[anodos]

OK, but if my ACL is set to linux, then it should be fine, right?

If it's set to Unix then it may be fine, unless you've been switching back and forth between Windows and Unix. I believe that doing this may leave your ACLs in an inconsistent state, which can produce erratic behavior.

When properly configured using the method I linked above, permissions will be properly inherited. If things aren't working right, then bug reports should be made to fix the behavior. It's generally better to do things the documented / intended way. It makes it easier to get support on forums and IRC, and makes it easier to fix bugs if you find a legitimate bug.

Edit: I just did a simple test on a "Unix share" dataset. When shared via CIFS, the zfsacl vfs module and associated parameters are enabled. This means there is no way to avoid nfsv4 ACLs. Only use "Windows share" datasets with CIFS, and embrace the better way of doing things. :D