[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.

After some experimentation, I found that I could so the same chgrp as a 
test user on another file server.

I restart nfs-idmap on the NFS file server, and now the chgrp operation 
is working under NFSv4.1.

Jason.