Jeremy Allison
2021-Feb-10 21:52 UTC
[Samba] urgent problem with samba 4.13 and chown/chgrp
On Wed, Feb 10, 2021 at 03:49:57PM -0500, Jason Keltz via samba wrote:>I'm trying to use chown/chgrp commands on files on NFS storage. > >Take a file "l" that I touched: > >-rw------- 1 jas tech 0 Feb 10 15:21 l > >(note that user and group mapping is working perfectly) > >% chgrp core l >chgrp: changing group of ?l?: Invalid argument > >The problem is not the group: > >% getent group core >core:x:1001: > >% wbinfo -n 'core' >S-1-5-21-1981678738-1545235886-4256466701-6765 SID_DOM_GROUP (2) > >% wbinfo -Y 'S-1-5-21-1981678738-1545235886-4256466701-6765' >1001 > >The problem is not the user: > >% getent passwd jas > >jas:*:1004:1000::/cs/home/jas:/cs/local/bin/tcsh > >When looking at an strace of the chgrp above, I see this odd call: > >fchownat(AT_FDCWD, "l", -1, 1001, 0) = -1 EINVAL (Invalid argument) > >Where the third argument should be my uid 1004 and is instead -1.-1 means "no change". From man fchownat: "If the owner or group is specified as -1, then that ID is not changed.">In smb.conf: > >idmap config * : backend = tdb >idmap config * : range = 1000000-1999999 > ># idmap config for the EECSYORKUCA domain ># range should match UNIX ID in AD > >idmap config EECSYORKUCA : backend = ad >idmap config EECSYORKUCA : schema_mode = rfc2307 >idmap config EECSYORKUCA : range = 1000-999999 >idmap config EECSYORKUCA : unix_primary_group = yes >idmap config EECSYORKUCA : unix_nss_info = yes > >Yes, and in /etc/nsswitch.conf: > >passwd:???? files winbind >shadow:???? files >group:????? files winbind > >As a side note, if I try to change the ownership of the file, I get a >similar behaviour. > >This is a showstopper if I can't get this figured out. :( panic >setting in.... > >(I'm positive I used chown/chgrp with 4.11 successfully.)You'll almost certainly need "root squash" on your NFS export. https://www.systutorials.com/how-to-allow-root-access-to-nfs/ Remember, Samba does activities as root which are by default disallowed over NFS.
On 2/10/2021 4:52 PM, Jeremy Allison wrote:> On Wed, Feb 10, 2021 at 03:49:57PM -0500, Jason Keltz via samba wrote: >> I'm trying to use chown/chgrp commands on files on NFS storage. >> >> Take a file "l" that I touched: >> >> -rw------- 1 jas tech 0 Feb 10 15:21 l >> >> (note that user and group mapping is working perfectly) >> >> % chgrp core l >> chgrp: changing group of ?l?: Invalid argument >> >> The problem is not the group: >> >> % getent group core >> core:x:1001: >> >> % wbinfo -n 'core' >> S-1-5-21-1981678738-1545235886-4256466701-6765 SID_DOM_GROUP (2) >> >> % wbinfo -Y 'S-1-5-21-1981678738-1545235886-4256466701-6765' >> 1001 >> >> The problem is not the user: >> >> % getent passwd jas >> >> jas:*:1004:1000::/cs/home/jas:/cs/local/bin/tcsh >> >> When looking at an strace of the chgrp above, I see this odd call: >> >> fchownat(AT_FDCWD, "l", -1, 1001, 0) = -1 EINVAL (Invalid argument) >> >> Where the third argument should be my uid 1004 and is instead -1. > > -1 means "no change". > > ?From man fchownat: > > "If the owner or group is specified as -1, then that ID is not changed." >So why would this call receive "invalid argument" then? In fact, even crazier new discovery: Over an NFSv3 mount, it works: fchownat(AT_FDCWD, "a", -1, 1001, 0)??? = 0 But over NFSv4.1 mount it fails as above.? This seems like a bug somewhere to me.? IT works on NFSv3.? It works on the local filesystem.? However, NFSv4.1 has a problem.>> In smb.conf: >> >> idmap config * : backend = tdb >> idmap config * : range = 1000000-1999999 >> >> # idmap config for the EECSYORKUCA domain >> # range should match UNIX ID in AD >> >> idmap config EECSYORKUCA : backend = ad >> idmap config EECSYORKUCA : schema_mode = rfc2307 >> idmap config EECSYORKUCA : range = 1000-999999 >> idmap config EECSYORKUCA : unix_primary_group = yes >> idmap config EECSYORKUCA : unix_nss_info = yes >> >> Yes, and in /etc/nsswitch.conf: >> >> passwd:???? files winbind >> shadow:???? files >> group:????? files winbind >> >> As a side note, if I try to change the ownership of the file, I get a >> similar behaviour. >> >> This is a showstopper if I can't get this figured out. :( panic >> setting in.... >> >> (I'm positive I used chown/chgrp with 4.11 successfully.) > > You'll almost certainly need "root squash" on your NFS > export. > > https://www.systutorials.com/how-to-allow-root-access-to-nfs/ > > Remember, Samba does activities as root which are by > default disallowed over NFS. >NFS root squash isn't needed for it to work on NFSv3. I've tested, and NFS root squash does not solve this problem (and I know it's active because if I touch a file as root it works as expected). My temporary solution was incorrect.? I was in the wrong directory.? I don't have a solution which is very unfortunate. Jason.