Subdirectories being created with 000 permissions and ? owner/group

[miucce]

Here's the scenario. SMB share from TrueNAS is mounted on RHEL box using multiuser and an AD service account. AD user can create directories and files just fine. Running getfacl on that mount point on the RHEL box gives me owner: root, group: domain\040users. user::rwx, group::rwx, owner::rwx.
AD user creates directory under root of share. Directory by default gets permission 0777, owner is AD user, group is Domain Users (AD group). Context is system_[URL='https://www.reddit.com/u/object_r/']u/object_r[/URL]/cifs_t/s0.
AD user creates directory under that one. Ownership, permissions, context are all the same as the first one.
Note that the first subdirectory has mode 0777. If the AD user does a chmod on it, even a chmod 0777, then tries to mkdir a subdirectory, it says mkdir: cannot create directory: permission denied. If I then to an ls -laZ in the parent, the new subdirectory has mode ?---------, owner ?, group ?, and the context section is just blank.
If I go to the TrueNAS machine's Shell and stat that directory, I can see its mode is now 0000.

What is it that would cause this?

Before the chmod, if I run getfacl from the NAS onto the subdirectory, I get:

Code:

owner@:rwxpDdaARWcCos:fd----I:allow
group@:rwxpDdaARWcCos:fd----I:allow
everyone@:rwxpDdaARWc--s:fd----I:allow
everyone@:--------------:fd----I:allow

then after the chmod:

Code:

group:ad-test-user:rwxpDdaARWcCo-:-------:allow
owner@:rwxpDdaARWcCo-:-------:allow
group@:rwxpDdaARWcCo-:-------:allow
everyone@:rwxpDdaARWcCo-:-------:allow
everyone@:--------------:fd-----:allow

See how the s:fd is gone from all the entries? It's confusing that everyone@ is there twice and that the AD account entry appears suddenly after the chmod.
Note that at all times, I can create files under a subdirectory, it's only creating directories under it that get the 0000 mode.

 

[miucce]

Sorry, I copied this from my Reddit post and some markup from there snuck in.
Context is system_u/object_r/cifs_t/s0.
Should say
Context is system_u/object_r/cifs_t/s0.

 

[anodos]

Can you provide output of "testparm -s"?

 

[anodos]

Also is this over SMB1 with Unix Extensions or SMB2/3?

 

[anodos]

A pcap of this might also be useful. If you feel uncomfortable posting details here, send me them via PM.

 

[miucce]

Hello, thank you for the response. Here's the output of testparm -s:

Code:

Warning: settings changed through the CLI are not written to
the configuration database and will be reset on reboot.

root@nasbox[~]# testparm -s
Load smb config files from /usr/local/etc/smb4.conf
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER

# Global parameters
[global]
        aio max threads = 2
        allow trusted domains = No
        bind interfaces only = Yes
        client ldap sasl wrapping = seal
        disable spoolss = Yes
        dns proxy = No
        domain master = No
        enable web service discovery = Yes
        kerberos method = secrets and keytab
        kernel change notify = No
        load printers = No
        local master = No
        logging = file
        max log size = 51200
        nsupdate command = /usr/local/bin/samba-nsupdate -g
        preferred master = No
        realm = DOM.EXAMPLE.COM
        registry shares = Yes
        restrict anonymous = 2
        security = ADS
        server role = member server
        server string = TrueNAS Server
        template shell = /bin/sh
        unix extensions = No
        winbind cache time = 7200
        winbind enum groups = Yes
        winbind enum users = Yes
        winbind max domain connections = 10
        winbind use default domain = Yes
        workgroup = DOM
        idmap config *: range = 90000001-100000000
        idmap config dom: range = 716400000-816400000
        idmap config dom: backend = rid
        idmap config * : backend = tdb
        directory name cache size = 0
        dos filemode = Yes


[Share]
        ea support = No
        kernel share modes = No
        path = /mnt/Pool/Dataset
        posix locking = No
        read only = No
        vfs objects = aio_fbsd streams_xattr shadow_copy_zfs ixnas
        nfs4:chown = true

The RHEL clients all mount the SMB share with vers=3.0 specified in their fstabs:

Code:

\\nasbox.dom.example.com\Share  /mel-share  cifs  nofail,sec=krb5i,domain=DOM,vers=3.0,multiuser,cruid=svc_fs,cifsacl,_netdev  0 0

As for pcap, does that refer to capturing the network traffic with something like Wireshark? What steps/actions would you like to me to do to capture the traffic for?

 

[anodos]

Hello, thank you for the response. Here's the output of testparm -s:

Code:

Warning: settings changed through the CLI are not written to
the configuration database and will be reset on reboot.

root@nasbox[~]# testparm -s
Load smb config files from /usr/local/etc/smb4.conf
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER

# Global parameters
[global]
        aio max threads = 2
        allow trusted domains = No
        bind interfaces only = Yes
        client ldap sasl wrapping = seal
        disable spoolss = Yes
        dns proxy = No
        domain master = No
        enable web service discovery = Yes
        kerberos method = secrets and keytab
        kernel change notify = No
        load printers = No
        local master = No
        logging = file
        max log size = 51200
        nsupdate command = /usr/local/bin/samba-nsupdate -g
        preferred master = No
        realm = DOM.EXAMPLE.COM
        registry shares = Yes
        restrict anonymous = 2
        security = ADS
        server role = member server
        server string = TrueNAS Server
        template shell = /bin/sh
        unix extensions = No
        winbind cache time = 7200
        winbind enum groups = Yes
        winbind enum users = Yes
        winbind max domain connections = 10
        winbind use default domain = Yes
        workgroup = DOM
        idmap config *: range = 90000001-100000000
        idmap config dom: range = 716400000-816400000
        idmap config dom: backend = rid
        idmap config * : backend = tdb
        directory name cache size = 0
        dos filemode = Yes


[Share]
        ea support = No
        kernel share modes = No
        path = /mnt/Pool/Dataset
        posix locking = No
        read only = No
        vfs objects = aio_fbsd streams_xattr shadow_copy_zfs ixnas
        nfs4:chown = true

The RHEL clients all mount the SMB share with vers=3.0 specified in their fstabs:

Code:

\\nasbox.dom.example.com\Share  /mel-share  cifs  nofail,sec=krb5i,domain=DOM,vers=3.0,multiuser,cruid=svc_fs,cifsacl,_netdev  0 0

As for pcap, does that refer to capturing the network traffic with something like Wireshark? What steps/actions would you like to me to do to capture the traffic for?

Just capture chmod request. tcpdump -i <your interface> -w /tmp/smb.pcap host <ip of centos box> and port 445 from TrueNAS should be fine.

 

[miucce]

Sorry for the late reply. Here's the packet capture as requested. It's zipped in accordance with file upload policies on this forum.
192.168.250.100 is the workstation and 192.168.250.38 is the TrueNAS machine.
My colleague prepared this, and simply ran "chmod 0777 test1" where "test1" was a directory on the NAS.

 

[anodos]

Well, that's annoying. You can see the chmod request converted into an SMB2 SETINFO request in frame 23. Client is explicitly stripping the inheritance bits from the directory's ACL, which we obligingly do to the detriment of your permissions. Perhaps an SMB client bug that is evident in our case because we have native NFSv4 ACLs. Does it do the same if you try to chmod an SMB share on a Windows server?

 

[miucce]

This is a similar PCAP from the same workstation against a shared directory on a test Windows 10 machine we had.
Mounted via nofail,sec=krb5i,domain=DOM,vers=3.0,multiuser,cruid=<domain user>,cifsacl

 

[anodos]

This is a similar PCAP from the same workstation against a shared directory on a test Windows 10 machine we had.
Mounted via nofail,sec=krb5i,domain=DOM,vers=3.0,multiuser,cruid=<domain user>,cifsacl

Okay. I see a problem. I'll send you a fix candidate later today or tomorrow through PM.

 

[anodos]

Sent patched version via private message that should fix the issue. This specifically impacts users with mount option `cifsacl` and is due to some of the intricacies of ACL inheritance with native NFSv4 ACLs.

 

[anodos]

Fix for this issue is merged for 12.0-U3.