[Samba] Permission denied when chainbuilding packages with mock

[Julian Sikorski]

W dniu 28.09.2021 o 19:38, Julian Sikorski via samba pisze:
> Am 28.09.21 um 13:11 schrieb Julian Sikorski via samba:
>> Am 28.09.21 um 12:58 schrieb Julian Sikorski via samba:
>>> W dniu 28.09.2021 o 12:10, Rowland Penny via samba pisze:
>>>> On Tue, 2021-09-28 at 11:28 +0200, Julian Sikorski via samba wrote:
>>>>> W dniu 28.09.2021 o 11:08, Rowland Penny via samba pisze:
>>>>>> On Tue, 2021-09-28 at 10:53 +0200, Julian Sikorski via samba wrote:
>>>>>>> Hi list,
>>>>>>>
>>>>>>> since a few weeks I am no longer able to chainbuild packages with
>>>>>>> mock
>>>>>>> when localrepo is pointed to a samba share.
>>>>>>
>>>>>> Has anything changed, any updares etc ?
>>>>>
>>>>
>>>> At the top of the client smb.conf is this:
>>>>
>>>> # Note:
>>>> # SMB1 is disabled by default. This means clients without support for
>>>> SMB2 or
>>>> # SMB3 are no longer able to connect to smbd (by default).
>>>>
>>>> It should also say that if you are trying to connect to a server, then
>>>> the server  must not use SMBv1 because the client doesn't use SMBv1.
>>>>
>>>> Try adding these lines to the smb.conf on the server:
>>>>
>>>> client min protocol = SMB2
>>>> server min protocol = SMB2
>>>>
>>>> Reload the config, do not restart Samba, OMV may remove the lines.
>>>>
>>>> If they work (and they should), you need to find out how to stop OMV
>>>> from removing them.
>>>>
>>>> Rowland
>>>>
>>> Thanks! I added the lines, reloaded the config with smbcontrol smbd 
>>> reload-config and remounted the share on the client. It did not help 
>>> unfortunately. As I have vers=3.1.1 in the fstab entry, shouldn't 
>>> this have been sufficient?
>>> In the meantime, I have tried something else and got some interesting 
>>> results. I have tried to remove as many variables as possible and I 
>>> did the following:
>>>
>>> 1. removed nobrl from the mount options on the desktop client to 
>>> align with my laptop client
>>> 2. attempted to run the same rebuild command from my other client, 
>>> using exactly the same mock options and as close as possible mount 
>>> options. I then tried chainbuilding two different packages: $ mock 
>>> --chain --localrepo /mnt/openmediavault/kernel/ -r fedora-34-x86_64 
>>> goffice/goffice-0.10.50-2.fc36.src.rpm 
>>> gnumeric/gnumeric-1.12.50-2.fc36.src.rpm. This has led to some 
>>> interesting results: initially, if the first attempt was made on the 
>>> desktop pc, the access denied error would appear and subsequent 
>>> attempts on the laptop will fail. On the other hand, if the first 
>>> attempt was made on the laptop, subsequent attempts would succeed, 
>>> including ones done on the desktop. After changing and reverting the 
>>> protocol version, however, neither laptop nor desktop clients work.
>>>
>>> The above indicates that the package versions installed can work in 
>>> theory as I did no updates in the meantime. The question remains what 
>>> is causing the failures.
>>>
>>> Best regards,
>>> Julian
>>>
>> I am making some assumptions here, but it appears that once a folder 
>> has been generated from the desktop once, the bogus (?) ACLs remain 
>> for a while and deleting the folder does not help. Case in point: I 
>> delete the goffice* and repodata folders from 
>> /mnt/openmediavault/kernel/results, but
>>
>> $ mock --chain --localrepo=/mnt/openmediavault/kernel -r 
>> fedora-34-x86_64 goffice/goffice-0.10.49-1.fc36.src.rpm 
>> gnumeric/gnumeric-1.12.49-1.fc36.src.rpm
>>
>> will keep working from the laptop as goffice-0.10.49 was never rebuilt 
>> from the desktop, but
>>
>> $ mock --chain --localrepo=/mnt/openmediavault/kernel -r 
>> fedora-34-x86_64 goffice/goffice-0.10.50-2.fc36.src.rpm 
>> gnumeric/gnumeric-1.12.50-2.fc36.src.rpm
>>
>> will fail when run from the laptop, even if the goffice-0.10.50-2.fc36 
>> folder does not exist when the build is started.
>>
>> Best regards,
>> Julian
>>
> What makes this even more strange is that building to a different folder 
> on the share does not help, i.e.
> 
> $ mock --chain --localrepo=/mnt/openmediavault/kernel1 -r 
> fedora-34-x86_64 goffice/goffice-0.10.50-2.fc36.src.rpm 
> gnumeric/gnumeric-1.12.50-2.fc36.src.rpm
> 
> Moreover, I have checked the logs and there are no 
> NT_STATUS_NO_EAS_ON_FILE or NT_STATUS_ACCESS_DENIED entries in it when 
> running the goffice-0.10.49-1.fc36.src.rpm and 
> gnumeric-1.12.49-1.fc36.src.rpm rebuild which suggests that these have 
> something to do with the failure.
> What I do not really understand is that starting in an empty folder does 
> not help. Does samba cache the permissions somewhere where they could 
> survive the deletion of the file?
> 
> Best regards,
> Julian
> 
> 
I have upgraded to Fedora 35 hoping this issue would go away, it 
unfortunately did not. Is samba even supposed to support fsync? If so, 
how else can I investigate this further?

Best regards,
Julian