[Samba] vfs_ChDir failed: Permission denied

[Rowland penny]

On 31/01/2021 16:54, Marco Shmerykowsky via samba wrote:
> On 2021-01-31 11:45 am, Rowland penny via samba wrote:
>> On 31/01/2021 16:34, Marco Shmerykowsky via samba wrote:
>>>
>>> On 2021-01-31 11:23 am, Marco Shmerykowsky via samba wrote:
>>>> On 2021-01-31 11:18 am, Rowland penny via samba wrote:
>>>>> On 31/01/2021 16:05, Marco Shmerykowsky via samba wrote:
>>>>>> On 2021-01-31 10:41 am, Marco Shmerykowsky via samba wrote:
>>>>>>> On 2021-01-31 10:15 am, Rowland penny via samba wrote:
>>>>>>>> On 31/01/2021 14:42, Marco Shmerykowsky via samba wrote:
>>>>>>>>>
>>>>>>>>> I found the errors in the smbd log file on the domain member
>>>>>>>>> server that contains the file shares.  I have group policies
>>>>>>>>> for the desktop background and drives shares.  The policies
>>>>>>>>> seem to be applied since the drive maps show up and I do
>>>>>>>>> not see any errors when I run gpresult.
>>>>>>>>>
>>>>>>>>> The background doesn't show up because the image file is
>>>>>>>>> stored in one of the drive shares.  Trying to access the
>>>>>>>>> drive shares results in an error under windows that I do
>>>>>>>>> not have permission to access the share.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Is there anything surrounding it (paths etc)
>>>>>>>>>
>>>>>>>>> The full line in the log is as follows:
>>>>>>>>>
>>>>>>>>>   chdir_current_service: 
>>>>>>>>> vfs_ChDir(/path/to/domain-member-server/share) failed: 
>>>>>>>>> Permission denied. Current token: uid=11105, gid=10513, 13 
>>>>>>>>> groups: 11105 10513 11119 11118 11120 11121 11122 11135 11138 
>>>>>>>>> 2004 2005 2007 2002
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Domain Member server.  It seemed to be working fine until the
>>>>>>>>> DNS changes.
>>>>>>>>>
>>>>>>>>> permissions via getfacl:
>>>>>>>>>
>>>>>>>>> # file: path/to/domain-member-server/share
>>>>>>>>> # owner: root
>>>>>>>>> # group: domain\040admins
>>>>>>>>> user::rwx
>>>>>>>>> user:root:rwx
>>>>>>>>> group::rwx
>>>>>>>>> group:domain\040admins:rwx
>>>>>>>>> group:owners:rwx
>>>>>>>>> mask::rwx
>>>>>>>>> other::---
>>>>>>>>> default:user::rwx
>>>>>>>>> default:user:root:rwx
>>>>>>>>> default:group::r-x
>>>>>>>>> default:group:domain\040admins:r-x
>>>>>>>>> default:group:owners:rwx
>>>>>>>>> default:mask::rwx
>>>>>>>>> default:other::---
>>>>>>>>>
>>>>>>>>> Permissions via ls -la:
>>>>>>>>>
>>>>>>>>> drwxrwx---+  14 root domain admins  4096 Jan 25 16:12 share
>>>>>>>>
>>>>>>>>
>>>>>>>> From the data supplied, only root and members of the groups 
>>>>>>>> 'Domain
>>>>>>>> Admins & owners' can enter the share. You are connecting as a user
>>>>>>>> with the ID 11105 and primary group Domain Users, but does the 
>>>>>>>> group
>>>>>>>> 'owners' have one of these GID's '11119 11118 11120 11121 11122 
>>>>>>>> 11135
>>>>>>>> 11138'
>>>>>>>
>>>>>>> I believe the answer is 'yes.'  Under windows, the user 
>>>>>>> attempting to
>>>>>>> log in is a member of the group 'owners'
>>>>>>>
>>>>>>> running 'wbinfo --name-to-sid user' returns:
>>>>>>>
>>>>>>> S-1-5-21-816939725-271653577-1537739732-1105 SID_USER (1)
>>>>>>>                                         ^^^^
>>>>>>>
>>>>>>> running 'wbinfo --name-to-sid group' returns:
>>>>>>>
>>>>>>> S-1-5-21-816939725-271653577-1537739732-1118 SID_DOM_GROUP (2)
>>>>>>>                                         ^^^^
>>>>>>
>>>>>> Correction, the gid seems to be off by 10000.
>>>>>>
>>>>>
>>>>> Yes and no 😂
>>>>>
>>>>> What you were pointing to, was the RID and you are using the winbind
>>>>> rid backend, which means the groups GID is calculated from this
>>>>> formula:
>>>>>
>>>>> ID = RID + LOW_RANGE_ID
>>>>>
>>>>> Which becomes for you:
>>>>>
>>>>> 11105 = 1105 + 10000
>>>>
>>>> Ah... Learning, learning, learning
>>>>
>>>>>
>>>>> Does 'getent group owners' produce '11105' as the first number in 
>>>>> the output ?
>>>>>
>>>>> If it doesn't, what is the groupname produced by 'getent group 
>>>>> 11105' ?
>>>>
>>>> 'getent group owners' returns:
>>>>
>>>> AD-DOMAIN\owners:x:3000025:
>>>
>>> I think I know how I created this problem.
>>>
>>> about a week ago when upgrading from samba-4.9-Stretch to 
>>> samba-4.13-buster
>>> I caught an error in the smb.conf that was in there since I set 
>>> things up
>>>
>>> The line 'idmap config AD-DOMAIN : range = 10000-999999' had a typo
>>> in the word "config" I believe.  For some reason, everything continued
>>> to work after the correction and then fell apart after I corrected
>>> the dns issues (i hope)
>>>
>>> How do I fix my error, if that is indeed the issue?
>>>
>>> Thank you.
>>>
>>
>> Samba has a program called 'testparm', running this will test smb.conf
>> and report any errors.
>
> Yea. I've used it.  Don't know how this slipped by me.
>>
>> I think what happened was that Samba ignored your malformed line and
>> everything ended up in the default (*) domain. Now you have fixed the
>> problem, your users & groups will now have different numeric ID's, I
>> Do hope you don't have a lot of data on that computer.
>>
>
> Unfortunately, there is a ton of data.  On the upside, I was planning
> to move all this data to a new server in the next week or two.
>
> Is there a way to fix this either on the existing server or
> the new server?
>

Your problem will be in identifying the correct owners of the files, if 
everything looks okay now, I would very quickly setup a new Unix domain 
member and copy everything to the new one, this should work, but I would 
check  all ownerships on the new machine.

Rowland