[Samba] urgent problem with samba 4.13 and chown/chgrp

[Jason Keltz]

On 2/10/2021 6:09 PM, Jason Keltz via samba wrote:
> 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.

I have yet a different, but related problem...

Add the user to a new group... when the user logs into the system, and 
you run "groups", you can see he is in the group, but if you try to 
chgrp with that group, now the fchownat(AT_FDCWD, "l", -1, 2000, 0) 
operation returns   = -1 EPERM (Operation not permitted).  I know it's a 
winbind caching issue, so as a temporary hack, I tried to set in 
smb.conf "winbind cache time = 1", "idmap cache time =1", and "idmap 
negative cache time = 1". on both the client, and on the NFS server and 
this doesn't seem to change anything after restarting both winbinds.  I 
suspect in a few hours it might just work.  I rebooted one NFS client 
where it wasn't working, and that was enough to get winbind to see the 
new group membership.  Of course that's not the long term desirable 
solution. :)

Jason.