New files and directories receive unwanted explicit permissions on Windows share

[gregyski]

Hello. I've set up a new NAS and a Windows share on it and joined it to an existing domain. Most things are working correctly, however, when a new file or directory is created on the share (and not on other shares off the FreeNAS system) it's given three extraneous explicit permissions in addition to the expected inherited permissions for the following three users/groups: EVERYONE, DOMAIN\Domain Admins, DOMAIN\AdminName. Obviously the first one is the primary concern, although none of them should be created. I'd greatly appreciate help in diagnosing this. I've changed some names (DOMAIN, AdminName, etc.) for privacy, I hope that's okay.

This seems similar to https://forums.freenas.org/index.php?threads/cifs-permission-woes-on-new-files-and-folders.39605/ but as that is a couple years old and I didn't really understand if the user was able to resolve it using the suggestions provided, I decided it best to create a new thread.

I've configured as much as I can Windows-side using Computer Management->Connect to Computer to manipulate the share's permissions and Windows Explorer to manipulate the NTFS permissions.

Below I've included what information I thought relevant. Please let me know if there is anything else you need.

Code:

FreeNAS-11.0-U2 (e417d8aa5)

freenas# uname -a
FreeBSD freenas.domain.local 11.0-STABLE FreeBSD 11.0-STABLE #0 r313908+d7d07647f69(freenas/11.0-stable): Thu Jul 20 19:01:05 UTC 2017  root@gauntlet:/freenas-11-releng/freenas/_BE/objs/freenas-11-releng/freenas/_BE/os/sys/FreeNAS.amd64  amd64

Intel Xeon E3-1240v6
Supermicro X11SSM-F-O
64GB Kingston ValueRAM 16GB 2133MHz DDR4 ECC CL15 DIMM 2Rx8
Perc H200 flashed to 9211-8i IT Mode 20.00.07

Volume/dataset/share (ignore the extra VM zvol, it shouldn't be there and I need to move that to another pool):

Dataset permissions:

Share permissions:

Code:

freenas# zfs get aclmode v01_hdd-raidz2
NAME  PROPERTY  VALUE  SOURCE
v01_hdd-raidz2  aclmode  restricted  local

freenas# zfs get aclmode v01_hdd-raidz2/nas_00
NAME  PROPERTY  VALUE  SOURCE
v01_hdd-raidz2/nas_00  aclmode  restricted  local

freenas# getfacl /mnt/v01_hdd-raidz2/
# file: /mnt/v01_hdd-raidz2/
# owner: DOMAIN\administrator
# group: DOMAIN\domain admins
  owner@:rwxpDdaARWcCos:fd-----:allow
  group@:rwxpDdaARWcCos:fd-----:allow
  everyone@:r-x---a-R-c---:fd-----:allow
	
freenas# getfacl /mnt/v01_hdd-raidz2/nas_00
# file: /mnt/v01_hdd-raidz2/nas_00
# owner: DOMAIN\adminname
# group: DOMAIN\domain admins
group:DOMAIN\nas_00-writers:rwxpDdaARWc---:fd-----:allow
group:DOMAIN\nas_00-full:rwxpDdaARWcCo-:fd-----:allow
group:DOMAIN\administrator:rwxpDdaARWcCo-:fd-----:allow
group:DOMAIN\domain users:--x---a-------:-d-----:allow
group:BUILTIN\administrators:rwxpDdaARWcCo-:fd-----:allow

freenas# testparm
Load smb config files from /usr/local/etc/smb4.conf
Processing section "[nas_00]"
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER

/etc/local/smb4.conf:

Code:

[global]
  server max protocol = SMB3
  interfaces = 127.0.0.1 10.1.1.208 10.2.1.208
  bind interfaces only = yes
  encrypt passwords = yes
  dns proxy = no
  strict locking = no
  oplocks = yes
  deadtime = 15
  max log size = 51200
  max open files = 1884863
  logging = file
  load printers = no
  printing = bsd
  printcap name = /dev/null
  disable spoolss = yes
  getwd cache = yes
  guest account = nobody
  map to guest = Bad User
  obey pam restrictions = yes
  ntlm auth = no
  directory name cache size = 0
  kernel change notify = no
  panic action = /usr/local/libexec/samba/samba-backtrace
  nsupdate command = /usr/local/bin/samba-nsupdate -g
  server string = freenas
  ea support = yes
  store dos attributes = yes
  lm announce = yes
  acl allow execute always = true
  dos filemode = yes
  multicast dns register = yes
  domain logons = no
  idmap config *: backend = tdb
  idmap config *: range = 90000001-100000000
  server role = member server
  workgroup = DOMAIN
  realm = DOMAIN.LOCAL
  security = ADS
  client use spnego = yes
  local master = no
  domain master = no
  preferred master = no
  ads dns update = yes
  winbind cache time = 7200
  winbind offline logon = yes
  winbind enum users = yes
  winbind enum groups = yes
  winbind nested groups = yes
  winbind use default domain = no
  winbind refresh tickets = yes
  idmap config DOMAIN: backend = rid
  idmap config DOMAIN: range = 20000-90000000
  allow trusted domains = no
  client ldap sasl wrapping = plain
  template shell = /bin/sh
  template homedir = /home/%D/%U
  netbios name = FREENAS
  pid directory = /var/run/samba
  create mask = 0666
  directory mask = 0777
  client ntlmv2 auth = yes
  dos charset = CP437
  unix charset = UTF-8
  log level = 1


[nas_00]
  path = "/mnt/v01_hdd-raidz2/nas_00"
  printable = no
  veto files = /.snapshot/.windows/.mac/.zfs/
  writeable = yes
  browseable = yes
  shadow:snapdir = .zfs/snapshot
  shadow:sort = desc
  shadow:localtime = yes
  shadow:format = auto-%Y%m%d.%H%M-2w
  shadow:snapdirseverywhere = yes
  vfs objects = shadow_copy2 zfs_space zfsacl streams_xattr aio_pthread
  hide dot files = yes
  guest ok = no
  nfs4:mode = special
  nfs4:acedup = merge
  nfs4:chown = true
  zfsacl:acesort = dontcare
  access based share enum=yes

Thank you for any assistance you can provide.

 

[anodos]

Hello. I've set up a new NAS and a Windows share on it and joined it to an existing domain. Most things are working correctly, however, when a new file or directory is created on the share (and not on other shares off the FreeNAS system) it's given three extraneous explicit permissions in addition to the expected inherited permissions for the following three users/groups: EVERYONE, DOMAIN\Domain Admins, DOMAIN\AdminName. Obviously the first one is the primary concern, although none of them should be created. I'd greatly appreciate help in diagnosing this. I've changed some names (DOMAIN, AdminName, etc.) for privacy, I hope that's okay.

This seems similar to https://forums.freenas.org/index.php?threads/cifs-permission-woes-on-new-files-and-folders.39605/ but as that is a couple years old and I didn't really understand if the user was able to resolve it using the suggestions provided, I decided it best to create a new thread.

I've configured as much as I can Windows-side using Computer Management->Connect to Computer to manipulate the share's permissions and Windows Explorer to manipulate the NTFS permissions.

Below I've included what information I thought relevant. Please let me know if there is anything else you need.

Code:

FreeNAS-11.0-U2 (e417d8aa5)

freenas# uname -a
FreeBSD freenas.domain.local 11.0-STABLE FreeBSD 11.0-STABLE #0 r313908+d7d07647f69(freenas/11.0-stable): Thu Jul 20 19:01:05 UTC 2017  root@gauntlet:/freenas-11-releng/freenas/_BE/objs/freenas-11-releng/freenas/_BE/os/sys/FreeNAS.amd64  amd64

Intel Xeon E3-1240v6
Supermicro X11SSM-F-O
64GB Kingston ValueRAM 16GB 2133MHz DDR4 ECC CL15 DIMM 2Rx8
Perc H200 flashed to 9211-8i IT Mode 20.00.07

Volume/dataset/share (ignore the extra VM zvol, it shouldn't be there and I need to move that to another pool):

Dataset permissions:

Share permissions:

Code:

freenas# zfs get aclmode v01_hdd-raidz2
NAME  PROPERTY  VALUE  SOURCE
v01_hdd-raidz2  aclmode  restricted  local

freenas# zfs get aclmode v01_hdd-raidz2/nas_00
NAME  PROPERTY  VALUE  SOURCE
v01_hdd-raidz2/nas_00  aclmode  restricted  local

freenas# getfacl /mnt/v01_hdd-raidz2/
# file: /mnt/v01_hdd-raidz2/
# owner: DOMAIN\administrator
# group: DOMAIN\domain admins
  owner@:rwxpDdaARWcCos:fd-----:allow
  group@:rwxpDdaARWcCos:fd-----:allow
  everyone@:r-x---a-R-c---:fd-----:allow
	
freenas# getfacl /mnt/v01_hdd-raidz2/nas_00
# file: /mnt/v01_hdd-raidz2/nas_00
# owner: DOMAIN\adminname
# group: DOMAIN\domain admins
group:DOMAIN\nas_00-writers:rwxpDdaARWc---:fd-----:allow
group:DOMAIN\nas_00-full:rwxpDdaARWcCo-:fd-----:allow
group:DOMAIN\administrator:rwxpDdaARWcCo-:fd-----:allow
group:DOMAIN\domain users:--x---a-------:-d-----:allow
group:BUILTIN\administrators:rwxpDdaARWcCo-:fd-----:allow

/etc/local/smb4.conf:

Code:

[global]
  server max protocol = SMB3
  interfaces = 127.0.0.1 10.1.1.208 10.2.1.208
  bind interfaces only = yes
  encrypt passwords = yes
  dns proxy = no
  strict locking = no
  oplocks = yes
  deadtime = 15
  max log size = 51200
  max open files = 1884863
  logging = file
  load printers = no
  printing = bsd
  printcap name = /dev/null
  disable spoolss = yes
  getwd cache = yes
  guest account = nobody
  map to guest = Bad User
  obey pam restrictions = yes
  ntlm auth = no
  directory name cache size = 0
  kernel change notify = no
  panic action = /usr/local/libexec/samba/samba-backtrace
  nsupdate command = /usr/local/bin/samba-nsupdate -g
  server string = freenas
  ea support = yes
  store dos attributes = yes
  lm announce = yes
  acl allow execute always = true
  dos filemode = yes
  multicast dns register = yes
  domain logons = no
  idmap config *: backend = tdb
  idmap config *: range = 90000001-100000000
  server role = member server
  workgroup = DOMAIN
  realm = DOMAIN.LOCAL
  security = ADS
  client use spnego = yes
  local master = no
  domain master = no
  preferred master = no
  ads dns update = yes
  winbind cache time = 7200
  winbind offline logon = yes
  winbind enum users = yes
  winbind enum groups = yes
  winbind nested groups = yes
  winbind use default domain = no
  winbind refresh tickets = yes
  idmap config DOMAIN: backend = rid
  idmap config DOMAIN: range = 20000-90000000
  allow trusted domains = no
  client ldap sasl wrapping = plain
  template shell = /bin/sh
  template homedir = /home/%D/%U
  netbios name = FREENAS
  pid directory = /var/run/samba
  create mask = 0666
  directory mask = 0777
  client ntlmv2 auth = yes
  dos charset = CP437
  unix charset = UTF-8
  log level = 1


[nas_00]
  path = "/mnt/v01_hdd-raidz2/nas_00"
  printable = no
  veto files = /.snapshot/.windows/.mac/.zfs/
  writeable = yes
  browseable = yes
  shadow:snapdir = .zfs/snapshot
  shadow:sort = desc
  shadow:localtime = yes
  shadow:format = auto-%Y%m%d.%H%M-2w
  shadow:snapdirseverywhere = yes
  vfs objects = shadow_copy2 zfs_space zfsacl streams_xattr aio_pthread
  hide dot files = yes
  guest ok = no
  nfs4:mode = special
  nfs4:acedup = merge
  nfs4:chown = true
  zfsacl:acesort = dontcare
  access based share enum=yes

Thank you for any assistance you can provide.

What is the aclmode for the dataset you're sharing? zfs get aclmode pool/dataset

 

[gregyski]

Thanks for your assistance, anodos. Here is that information:

Code:

freenas# zfs get aclmode v01_hdd-raidz2
NAME  PROPERTY  VALUE  SOURCE
v01_hdd-raidz2  aclmode  restricted  local

freenas# zfs get aclmode v01_hdd-raidz2/nas_00
NAME  PROPERTY  VALUE  SOURCE
v01_hdd-raidz2/nas_00  aclmode  restricted  local

I've done some experimenting, and I find that if I create a new directory inside root, then break inheritance from root and give that directory its own permissions, that any subdirectories and files I create in that directory are now clean of the problem. So the problematic permissions seem to be inheriting from share root even though (a) they don't show up as permissions of the share root and (b) they show up as explicit permissions (they show as "Inherited from: None" or "<not inherited>" depending on version of Windows) and not inherited ones.

If I copy one of the files that contain the extraneous explicit permissions over to the non-inheriting test directory I mention above, it loses all the extraneous permissions and only contains the inherited permissions of the new parent directory, like it should.

Something is clearly wonky.

I suspect I can just work around the problem by creating a sub-directory on root, break inheritance on it, set it's perms the way I want, and move everything else into it. But I'd rather look into this further because it's the right thing to do - if there's a bug it's best to find it for the sake of the relevant project - if it's a misconfiguration it's best to fix it to avoid gotchas down the road.

 

[anodos]

Hello. I've set up a new NAS and a Windows share on it and joined it to an existing domain. Most things are working correctly, however, when a new file or directory is created on the share (and not on other shares off the FreeNAS system) it's given three extraneous explicit permissions in addition to the expected inherited permissions for the following three users/groups: EVERYONE, DOMAIN\Domain Admins, DOMAIN\AdminName. Obviously the first one is the primary concern, although none of them should be created. I'd greatly appreciate help in diagnosing this. I've changed some names (DOMAIN, AdminName, etc.) for privacy, I hope that's okay.

This seems similar to https://forums.freenas.org/index.php?threads/cifs-permission-woes-on-new-files-and-folders.39605/ but as that is a couple years old and I didn't really understand if the user was able to resolve it using the suggestions provided, I decided it best to create a new thread.

I've configured as much as I can Windows-side using Computer Management->Connect to Computer to manipulate the share's permissions and Windows Explorer to manipulate the NTFS permissions.

Below I've included what information I thought relevant. Please let me know if there is anything else you need.

Code:

FreeNAS-11.0-U2 (e417d8aa5)

freenas# uname -a
FreeBSD freenas.domain.local 11.0-STABLE FreeBSD 11.0-STABLE #0 r313908+d7d07647f69(freenas/11.0-stable): Thu Jul 20 19:01:05 UTC 2017  root@gauntlet:/freenas-11-releng/freenas/_BE/objs/freenas-11-releng/freenas/_BE/os/sys/FreeNAS.amd64  amd64

Intel Xeon E3-1240v6
Supermicro X11SSM-F-O
64GB Kingston ValueRAM 16GB 2133MHz DDR4 ECC CL15 DIMM 2Rx8
Perc H200 flashed to 9211-8i IT Mode 20.00.07

Volume/dataset/share (ignore the extra VM zvol, it shouldn't be there and I need to move that to another pool):

Dataset permissions:

Share permissions:

Code:

freenas# zfs get aclmode v01_hdd-raidz2
NAME  PROPERTY  VALUE  SOURCE
v01_hdd-raidz2  aclmode  restricted  local

freenas# zfs get aclmode v01_hdd-raidz2/nas_00
NAME  PROPERTY  VALUE  SOURCE
v01_hdd-raidz2/nas_00  aclmode  restricted  local

freenas# getfacl /mnt/v01_hdd-raidz2/
# file: /mnt/v01_hdd-raidz2/
# owner: DOMAIN\administrator
# group: DOMAIN\domain admins
  owner@:rwxpDdaARWcCos:fd-----:allow
  group@:rwxpDdaARWcCos:fd-----:allow
  everyone@:r-x---a-R-c---:fd-----:allow
	
freenas# getfacl /mnt/v01_hdd-raidz2/nas_00
# file: /mnt/v01_hdd-raidz2/nas_00
# owner: DOMAIN\adminname
# group: DOMAIN\domain admins
group:DOMAIN\nas_00-writers:rwxpDdaARWc---:fd-----:allow
group:DOMAIN\nas_00-full:rwxpDdaARWcCo-:fd-----:allow
group:DOMAIN\administrator:rwxpDdaARWcCo-:fd-----:allow
group:DOMAIN\domain users:--x---a-------:-d-----:allow
group:BUILTIN\administrators:rwxpDdaARWcCo-:fd-----:allow

Okay. I sat down at a real computer to look properly at this. :)

It looks like you've removed the "owner@", "group@", and "everyone@" aces from the root of your share. These are special aces that exist for unix compatibility see the RFC for more details. The equivalent unix mode for this ACL is "000". Since there are no inheriting values set for them, FreeNAS is probably using the umask to to set these permissions for newly created files. Try the following:

• Reset permissions on the share winacl -a reset -r /mnt/v01_hdd-raidz2/nas_00
• Using the ACL editor on a windows computer, modify the permissions of "everyone" to have execute and read attributes. Leave permissions for the other two intact. This leaves default inheriting values for all your ACEs.
• Using the ACL editor, add your other permissions (DOMAIN\nas_00-writers, DOMAIN\nas_00-full, DOMAIN\administrator, DOMAIN\domain users, BUILTIN\administrators)

You may also want to consider adding the auxiliary parameter nfs4:mode = simple under Services-SMB. This changes how samba will display the ACEs associated with owner@ and group@ to SMB clients (specifically, as CREATOR-OWNER and CREATOR-OWNER GROUP respectively, which is a more accurate approach). I wrote up a bit about this here: https://bugs.freenas.org/issues/21603

In the big picture, I think it's a good idea to have some values set for the special ACEs (or at a minimum owner@). There is no way on a unix system to avoid granting the owner of a file / folder the ability to change its permissions. This means that CREATOR-OWNER always has de-facto "full control" because the owner can modify the permissions to grant full control. There are workarounds for this if it is undesirable, but it goes pretty far off-topic. :)

TL;DR - It's not a bug, it's a feature.

 

[gregyski]

Very interesting. Thank you so much for looking into this. I can see in retrospect via getfacl that those were special, but from the Windows ACL editor they just showed up as DOMAIN/Administrator, DOMAIN/Domain Admins, and Everyone, so I just removed them and replaced them with groups that contained DOMAIN/Administrator and DOMAIN/Domain Admins. I can see how that's bad now. :) I will try your suggestions but I won't be able to do it until tonight. I'll report back after I've tried them (and I already have a followup question or two for you which I will save until then). Thanks again!

 

[gregyski]

Actually, let me ask a few questions first, if I may.

1) Do I really need to run the winacl command recursively? I take it that will overwrite all my permissions across all my data. It's not the end of the world but it'll be a big job to put everything back. Ultimately, though, I want to get things "proper" more than I care about the expenditure of time.
2) Regarding the second and third steps, I believe any changes made to ACLs on root from Windows itself (since the Windows tools are necessarily remote to the FreeNAS share) will give the warning:

I had been ignoring that warning previously and I worried that it might be causing some of my issues. Should I worry about it?
3) Once things are reset properly, is there any harm in breaking inheritance outside of root (in a sub-directory) such that those special ACEs aren't inherited further into the structure?
4) You mention giving Everyone "execute" and "read attributes". I assume the reason for this is to give traverse rights (which I do want, although I was giving it to Domain Users instead of Everyone). Can I, however, give it to "This folder and subfolders" only and not to "This folder, subfolders and files" (which I assume would actually give execute rights on files)?

 

[anodos]

Actually, let me ask a few questions first, if I may.

1) Do I really need to run the winacl command recursively? I take it that will overwrite all my permissions across all my data. It's not the end of the world but it'll be a big job to put everything back. Ultimately, though, I want to get things "proper" more than I care about the expenditure of time.

Well, if you only need to add explicit inheriting ACEs for owner@, then you can do something like this: find /mnt/v01_hdd-raidz2/nas_00 -type d -exec setfacl -m owner@:full_set:fd:allow,group@:full_set:fd:allow,everyone@:xac:fd:allow {} ;\

This command will set values "full control" for owner@ and group@ for every directory on your share. If you want to tone it down some, you can do this: find /mnt/v01_hdd-raidz2/nas_00 -type d -exec setfacl -m owner@:modify_set:fd:allow,group@:modify_set:fd:allow {} ;\

then find /mnt/v01_hdd-raidz2/nas_00 -type d -exec setfacl -x everyone@::allow {} ;\
to remove any "everyone - allow" permissions across the share

2) Regarding the second and third steps, I believe any changes made to ACLs on root from Windows itself (since the Windows tools are necessarily remote to the FreeNAS share) will give the warning:

I had been ignoring that warning previously and I worried that it might be causing some of my issues. Should I worry about it?

I don't think it's what's causing your issues.

3) Once things are reset properly, is there any harm in breaking inheritance outside of root (in a sub-directory) such that those special ACEs aren't inherited further into the structure?

I haven't tested the precise conditions in which Samba will use the umask to generate values for these. I'd personally treat having some value for owner@ and group@ as a requirement for posix compatibility. In fact, the OS will lie to you if you delete the owner@ ace. The owner will still be able to execute setfacl and grant himself more rights. If for some reason you need to totally break inheritance at some point in the file tree, you will need to set your create mask and directory mask appropriately for those cases where samba will automatically generate non-inheriting ACEs for owner@, group@, and everyone@

4) You mention giving Everyone "execute" and "read attributes". I assume the reason for this is to give traverse rights (which I do want, although I was giving it to Domain Users instead of Everyone). Can I, however, give it to "This folder and subfolders" only and not to "This folder, subfolders and files" (which I assume would actually give execute rights on files)?

These are required for traverse rights. "read attributes" is required for a process to execute a stat() syscall on a file or directory. Unless the user has read attributes, he will be unable to determine whether the object is a file or directory and so the server does not present it to clients. It becomes "invisible".

They are not required for "everyone", but I've found it an easy way to ensure that traverse rights are present in standalone servers.

 

[anodos]

FYI, I also have a small write-up on Samba permissions in FreeNAS here: https://forums.freenas.org/index.php?threads/methods-for-fine-tuning-samba-permissions.50739/

 

[gregyski]

This is excellent information, thank you so much. I definitely did read your write-up back when I started setting up the NAS, and then again the other day before posting, but I can't pretend I groked it. I think a third time is in order. I feel I've learned quite a lot since then thanks to our investigations and discussions and may be able to understand it better.

I've been experimenting with test datasets and shares and have a few more questions/comments:

1) Am I correct in using the dataset->change permissions GUI to set Owner (user) to DOMAIN\Administrator and Owner (group) to DOMAIN\Domain Admins? I've had difficulty, even with the many excellent resources out there (and I've read/watched so very many), to find best practices for FreeNAS 11 joining an existing domain so I just want to be sure. I noted in your ticket regarding nfs4:mode that you left the special ACEs pointing to root and wheel, so perhaps I'm wrong in this. Actually your write-up seems to indicate this as well. But if that's the case, isn't it then necessary to give at least initial permissions to a Windows domain user on the share and filesystem via FreeNAS, since Windows won't allow you to change those since you aren't authenticated with it as root:wheel?

After having just re-read your write-up again, I suspect the answer is to set them to the defaults of root and wheel and use smbcacls or setfacl and sharesec to give initial permissions to my domain users, then do the rest from Windows.

2) I noticed something strange. On one of my test datasets where I had messed with the special @ ACEs, I ran:

Code:

winacl -a reset -r -p /mnt/v00_ssd-mirror/ds_nas_test_02

It did reset all ACLs in the dataset, however, when using the Windows GUI I noted that every directory and file showed the 3 permissions but they all showed as <not inherited> throughout the hierarchy. I then used the FreeNAS GUI->Dataset->Change Permissions->Set Permissions Recursively (Checked)->Change which I believe does something similar, and now all the permissions looked the same in Windows except they now showed as being inherited from the share root. I can see no difference in the output of getfacl for either scenario. Is this difference to be expected? Is one method superior?

3) I created new files and folders on that same test dataset (the one I reset via GUI and showed all files and folders as inheriting from share root). However, while the new files and folders do receive the same permissions, they show as <not inherited>. Again, is this to be expected? Should I be worrying about whether these special perms are showing as inherited or not?

I apologize if I'm being a bit dense. :)

 

[anodos]

This is excellent information, thank you so much. I definitely did read your write-up back when I started setting up the NAS, and then again the other day before posting, but I can't pretend I groked it. I think a third time is in order. I feel I've learned quite a lot since then thanks to our investigations and discussions and may be able to understand it better.

I've been experimenting with test datasets and shares and have a few more questions/comments:

1) Am I correct in using the dataset->change permissions GUI to set Owner (user) to DOMAIN\Administrator and Owner (group) to DOMAIN\Domain Admins? I've had difficulty, even with the many excellent resources out there (and I've read/watched so very many), to find best practices for FreeNAS 11 joining an existing domain so I just want to be sure. I noted in your ticket regarding nfs4:mode that you left the special ACEs pointing to root and wheel, so perhaps I'm wrong in this. Actually your write-up seems to indicate this as well. But if that's the case, isn't it then necessary to give at least initial permissions to a Windows domain user on the share and filesystem via FreeNAS, since Windows won't allow you to change those since you aren't authenticated with it as root:wheel?

After having just re-read your write-up again, I suspect the answer is to set them to the defaults of root and wheel and use smbcacls or setfacl and sharesec to give initial permissions to my domain users, then do the rest from Windows.

Any of these works. You can set it so that datasets are owned by root:wheel or bob:Domain Admins or whatever.

2) I noticed something strange. On one of my test datasets where I had messed with the special @ ACEs, I ran:

Code:

winacl -a reset -r -p /mnt/v00_ssd-mirror/ds_nas_test_02

It did reset all ACLs in the dataset, however, when using the Windows GUI I noted that every directory and file showed the 3 permissions but they all showed as <not inherited> throughout the hierarchy. I then used the FreeNAS GUI->Dataset->Change Permissions->Set Permissions Recursively (Checked)->Change which I believe does something similar, and now all the permissions looked the same in Windows except they now showed as being inherited from the share root. I can see no difference in the output of getfacl for either scenario. Is this difference to be expected?

I probably forgot to specify some switches in the winacl command I wrote up earlier. It's a fairly undocumented tool. :)

Is one method superior?

winacl is faster and can recurse. I personally like this tool: https://github.com/anodos325/cloneacl.py, but that's probably because I wrote it. cloneacl.py allows you to set a complex ACL at the root of a share, then push it down the entire file tree of the share. It also sets proper inheritance flag to show that the file is inherited (i), and accounts for edge cases where you want to set non-inheriting ACEs at the root of a share. I believe that support for (i) from userland tools like setfacl was relatively recently added to FreeBSD https://github.com/freebsd/freebsd/commit/db0a2c953d7c03e6526acbf76bee458a3e6543ce which makes something like my python script more desirable than simply using "find ./ -exec setfacl"

3) I created new files and folders on that same test dataset (the one I reset via GUI and showed all files and folders as inheriting from share root). However, while the new files and folders do receive the same permissions, they show as <not inherited>. Again, is this to be expected? Should I be worrying about whether these special perms are showing as inherited or not?

The best way to reset permissions for a share from the FreeNAS GUI is to use the "apply default permissions" checkbox in the share's menu. I can't remember off the top of my head how the permissions portion of the FreeNAS menu works in FreeNAS 11 (i.e. if it properly triggers a winacl reset).

I apologize if I'm being a bit dense. :)

Not a problem. The stuff is fairly complicated. It took me a few years of tinkering around and reading before I got where I am, which is probably only a few steps ahead of you. At some point you're going to need to experiment, find the answers, then contribute some documentation. :)

 

[gregyski]

Any of these works. You can set it so that datasets are owned by root:wheel or bob:Domain Admins or whatever.

Understood: either is okay. May I ask if you have a preference between those options and why? Because, if I'm not mistaken, the root:wheel owner option forces you to at least add one ACE from the FreeNAS CLI for a Windows user to be able to further edit the ACLs from within Windows (which isn't a big deal of course, now that I'm becoming fluent with setfacl).

I probably forgot to specify some switches in the winacl command I wrote up earlier. It's a fairly undocumented tool. :)

It sure seems to be. :) But, from the usage summary I don't see anything about inheritance.

I personally like this tool: https://github.com/anodos325/cloneacl.py

I gave your tool a try and had a weird occurrence with it. (An owner@:rw-p----------:-------:deny ACE appeared seemingly out of nowhere.) I'd have reported it as an issue except I haven't been able to replicate it! From briefly looking at the code, I can't see how it could happen if it wasn't in the directory the tool was invoked upon, but it wasn't. I'll play with it more later and if I can reproduce it I'll open a ticket. That's kind of off-topic for this discussion and I don't want to get side-tracked. (Although please feel free to contact me if you wish me to give it more intense attention.)

The best way to reset permissions for a share from the FreeNAS GUI is to use the "apply default permissions" checkbox in the share's menu. I can't remember off the top of my head how the permissions portion of the FreeNAS menu works in FreeNAS 11 (i.e. if it properly triggers a winacl reset).

I found this to not do anything to my existing shared dataset. As a test, I had modified the everyone@ ACE to everyone@:xa:d:allow, and completely deleted group@, and issuing that command didn't revert everyone@ or put group@ back. Maybe it couldn't do anything because root no longer is set as owner on that dataset and therefore couldn't? Or perhaps I'm misunderstanding what it is supposed to do. I do find that "FreeNAS GUI->Dataset->Change Permissions->Set Permissions Recursively (Checked)->Change" does recursively reset everything.

Not a problem. The stuff is fairly complicated. It took me a few years of tinkering around and reading before I got where I am, which is probably only a few steps ahead of you. At some point you're going to need to experiment, find the answers, then contribute some documentation. :)

Indeed. Until then, hopefully this post will be a treasure trove to those who follow in my staggering footsteps. Let me know when I have overextended my welcome with you, because I still have more to ask. :)

In my most recent testing, I've realized something that seems to go all the way back to my original question, and I believe is the source of much of my confusion: Window's display of inheritance does not seem to reflect the inheritance reported by getfacl nor, in fact, how the filesystem is behaving. For example, I performed the following:

Code:

$ sudo getfacl /mnt/v00_ssd-mirror/ds_nas_test_02/test06
# file: /mnt/v00_ssd-mirror/ds_nas_test_02/test06
# owner: DOMAIN\AdminName
# group: DOMAIN\domain admins
  owner@:rwxpDdaARWcCo-:fd----I:allow
  group@:rwxpDdaARWcCo-:fd----I:allow
  everyone@:--x---a-------:-d----I:allow

All show as inherited. But this appears in Windows as

Interestingly, if I perform the aforementioned "FreeNAS GUI->Dataset->Change Permissions->Set Permissions Recursively (Checked)->Change", Windows does show "Inherited From: \\FREENAS\sh_nas_test_02" for existing files and directories, but anything new mimics the aforementioned behavior where FreeNAS treats it as inherited, but Windows shows "Inherited From: <not inherited>".

What do you make of that? Is this the behavior you have noticed or have I perhaps broken something that's causing this. And do you think I should just ignore it knowing that FreeNAS is handling the inheritance properly in the background regardless of what Windows displays?

 

[anodos]

Understood: either is okay. May I ask if you have a preference between those options and why? Because, if I'm not mistaken, the root:wheel owner option forces you to at least add one ACE from the FreeNAS CLI for a Windows user to be able to further edit the ACLs from within Windows (which isn't a big deal of course, now that I'm becoming fluent with setfacl).

It sure seems to be. :) But, from the usage summary I don't see anything about inheritance.

That's why you need to read the source-code for it. https://github.com/freenas/freenas/blob/freenas/11.0-stable/src/winacl/winacl.c

I gave your tool a try and had a weird occurrence with it. (An owner@:rw-p----------:-------:deny ACE appeared seemingly out of nowhere.) I'd have reported it as an issue except I haven't been able to replicate it! From briefly looking at the code, I can't see how it could happen if it wasn't in the directory the tool was invoked upon, but it wasn't. I'll play with it more later and if I can reproduce it I'll open a ticket. That's kind of off-topic for this discussion and I don't want to get side-tracked. (Although please feel free to contact me if you wish me to give it more intense attention.)

I'll have to look at it another time. I barely have time to respond to forum posts these days. :( My knee-jerk reaction is that there's something going on at a lower-level on freebsd. owner@:deny aces can be generated when doing interesting things via chmod / setfacl. It might have to do with the OS lying about what permissions owner@ really has. I need to look into it more.

I found this to not do anything to my existing shared dataset. As a test, I had modified the everyone@ ACE to everyone@:xa:d:allow, and completely deleted group@, and issuing that command didn't revert everyone@ or put group@ back. Maybe it couldn't do anything because root no longer is set as owner on that dataset and therefore couldn't? Or perhaps I'm misunderstanding what it is supposed to do. I do find that "FreeNAS GUI->Dataset->Change Permissions->Set Permissions Recursively (Checked)->Change" does recursively reset everything.

That's good.

In my most recent testing, I've realized something that seems to go all the way back to my original question, and I believe is the source of much of my confusion: Window's display of inheritance does not seem to reflect the inheritance reported by getfacl nor, in fact, how the filesystem is behaving. For example, I performed the following:

Code:

$ sudo getfacl /mnt/v00_ssd-mirror/ds_nas_test_02/test06
# file: /mnt/v00_ssd-mirror/ds_nas_test_02/test06
# owner: DOMAIN\AdminName
# group: DOMAIN\domain admins
  owner@:rwxpDdaARWcCo-:fd----I:allow
  group@:rwxpDdaARWcCo-:fd----I:allow
  everyone@:--x---a-------:-d----I:allow

All show as inherited. But this appears in Windows as

One of the subtle differences between RFC 3530 (NFSv4) and RFC 5661 (NFSv4.1) is that the latter RFC has the ACE4_INHERITED_ACE flag. It's possible that something weird is going on in ./source3/modules/zfsacl.c with regard to the inherited_ace flag. Have you been playing around with the "nfs4:mode" parameter on this share? Perhaps you've done something to confuse windows.

Interestingly, if I perform the aforementioned "FreeNAS GUI->Dataset->Change Permissions->Set Permissions Recursively (Checked)->Change", Windows does show "Inherited From: \\FREENAS\sh_nas_test_02" for existing files and directories, but anything new mimics the aforementioned behavior where FreeNAS treats it as inherited, but Windows shows "Inherited From: <not inherited>".

Okay. You've definitely done something to confuse windows. Windows doesn't understand inheritance of special ACEs when you have nfs4:mode = special. Everything is good when the owner / owner-group of the file tree is consistent (for instance , after you reset permissions via the web ui), but all bets are off once new files are created. Perhaps try nfs4:mode = simple.

 

[gregyski]

One of the subtle differences between RFC 3530 (NFSv4) and RFC 5661 (NFSv4.1) is that the latter RFC has the ACE4_INHERITED_ACE flag. It's possible that something weird is going on in ./source3/modules/zfsacl.c with regard to the inherited_ace flag. Have you been playing around with the "nfs4:mode" parameter on this share? Perhaps you've done something to confuse windows.

Now that you mention it, I did add "nfs4:mode = simple" to "Services->SMB->Auxiliary parameters" back when you suggested I might want to look into it above (a couple days ago). I didn't notice any differences in the display of the special ACEs after doing so. I now note, however, that each share has its own "nfs4:mode" parameter in smb4.conf, and they are all set to "special" (which was not not explicitly set by me in the GUI, the only aux param I've been using for shares is "access based share enum=yes").

Okay. You've definitely done something to confuse windows. Windows doesn't understand inheritance of special ACEs when you have nfs4:mode = special. Everything is good when the owner / owner-group of the file tree is consistent (for instance , after you reset permissions via the web ui), but all bets are off once new files are created. Perhaps try nfs4:mode = simple.

As I have the SMB service currently set to simple, would you recommend I create a new test share with an Auxiliary parameter of "nfs4:mode = simple" and see if the behavior is any different? I'm unclear on whether that mode on the share needs to match the SMB service and if they don't match how it handles it.

 

[anodos]

Now that you mention it, I did add "nfs4:mode = simple" to "Services->SMB->Auxiliary parameters" back when you suggested I might want to look into it above (a couple days ago). I didn't notice any differences in the display of the special ACEs after doing so. I now note, however, that each share has its own "nfs4:mode" parameter in smb4.conf, and they are all set to "special" (which was not not explicitly set by me in the GUI, the only aux param I've been using for shares is "access based share enum=yes").

As I have the SMB service currently set to simple, would you recommend I create a new test share with an Auxiliary parameter of "nfs4:mode = simple" and see if the behavior is any different? I'm unclear on whether that mode on the share needs to match the SMB service and if they don't match how it handles it.

The behavior with nfs4:mode = simple is different in the following way: samba will generate two ACL entries for owner@ and group@

• CREATOR-OWNER - inheriting
• Unix owner - non-inheriting
• CREATOR OWNER GROUP - inheriting
• Unix group - non-inheriting

At that point, windows should report inheritance correctly.

 

[gregyski]

Understood, thank you. I wasn't seeing any additional ACL entries with SMB set to simple and shares set (unbeknownst to me) to special. I will try making a new dataset and share with it set to simple at the share level as well and retry my testing this evening.

 

[gregyski]

I've done a whole lot more testing. In my most recent test, I've rather happily failed to induce the "inheritance problem". I still need to test some more but I thought I'd report back my findings.

Unfortunately, I actually changed more than one thing for my last test, therefore making it impossible for me to be sure what made it more robust. I (1) made a completely new admin and non-admin user for the ownership and permissions, (2) performed all windows-side operations from Windows 10 instead of Server 2008R2 (the PDC), (3) created the share with "nfs4:mode=simple". I personally believe (3) was the key element (and was, of course, your suggested change). I would hope the other two wouldn't matter, but I'll have to do more testing to be sure. (Note that the SMB service was previously operating with "nfs4:mode=simple".)

For this test I:
1) Created a new dataset with all defaults except "Share Type: Windows"
2) Edited permissions on the dataset and set the Owner (user) to DOMAIN\TestAdmin and Owner (group) to DOMAIN\Domain Admins
3) Created directory dir01 which simply inherited from root, and subdir dir01_01 -> both showed proper inheritance
4) Created directory dir02 which inherited from root but to which I added read perms for DOMAIN\TestUser, and a subdir dir02_01 -> both showed proper inheritance
5) Created directory dir03 for which I broke inheritance from root but copied the root ACL then edited everyone@ ACE to have minimal traverse perms, and created a subdir dir03_01 -> they showed proper inheritance (where appropriate)
6) Edited share root everyone@ ACE to have minimal traverse perms -> dir01, dir02, and their subdirs showed the change and proper inheritance
7) I added a new read ACE for DOMAIN\TestUser to share root -> dir01, dir02, and their subdirs showed the new ACE and proper inheritance

So far so good, and in all previous tests at some point the "inheritance problem" would have reared its head.

I did notice something odd, however. Before I made any changes to the root share ACL, dir01 showed as:

Code:

# getfacl /mnt/v00_ssd-mirror/ds_nas_test_06/dir01
# file: /mnt/v00_ssd-mirror/ds_nas_test_06/dir01
# owner: DOMAIN\testadmin
# group: DOMAIN\domain admins
  owner@:rwxpDdaARWcCos:fd----I:allow
  group@:rwxpDdaARWcCos:fd----I:allow
  everyone@:r-x---a-R-c---:fd----I:allow

but after I made changes to the everyone@ ACE at share root it changed to:

Code:

# getfacl /mnt/v00_ssd-mirror/ds_nas_test_06/dir01
# file: /mnt/v00_ssd-mirror/ds_nas_test_06/dir01
# owner: DOMAIN\testadmin
# group: DOMAIN\domain admins
  owner@:rwxpDdaARWcCo-:-------:allow
  owner@:rwxpDdaARWcCo-:fdi----:allow
  group@:rwxpDdaARWcCo-:-------:allow
  group@:rwxpDdaARWcCo-:fdi----:allow
  everyone@:--x---a-------:-d-----:allow

I also saw the same behavior when I broke inheritance for dir03. Now this later result seems to match your description of the simple mode 'wart' from your feature request:

It actually displays two ACES for Owner@ and Group@ (as in a total of four of them): a non-inheriting ACE representing the owner / owner group, and an inheriting "CREATOR OWNER" and "CREATOR OWNER GROUP" (or whatever windows calls it), when there is only one Owner@ and Group@ ACE (because samba likes to lie about things / would make a great politician); and on new directories it will actually generate the additional non-inheriting Owner@ and Group@ ACEs

I just want to verify with you that this is expected from simple mode. I found it strange that it didn't change to showing the extra ACEs until after I edited the root ACL (affected /, /dir01, /dir02) or broke inheritance and copied the ACL (affected /dir03).

I'm also baffled as to why, while the inheritance now shows correctly in Windows, the ACEs lost their "uppercase I" inherited flag as you can see above.