[Samba] Permission denied when chainbuilding packages with mock

Thu Nov 4 20:17:29 UTC 2021

Am 04.11.21 um 20:16 schrieb Julian Sikorski via samba:
> 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
> 

I have tried to narrow the issue down further and I have found some 
bizarre results.

$ mock --chain --localrepo=/mnt/openmediavault/kernel -r 
fedora-35-x86_64 goffice/goffice-0.10.50-2.fc35.src.rpm 
gnumeric/gnumeric-1.12.50-2.fc36.src.rpm
^^ this fails every time with: Error calculating checksum 
/mnt/openmediavault/kernel/results/fedora-35-x86_64/goffice-0.10.50-2.fc35/goffice-0.10.50-2.fc35.x86_64.rpm: 
(39, fsync failed: Permission denied)

$ mock --chain --localrepo=/mnt/openmediavault/kernel -r 
fedora-35-x86_64 goffice/goffice-0.10.50-1.fc35.src.rpm 
gnumeric/gnumeric-1.12.50-2.fc36.src.rpm
^^ this works when starting with goffice and goffice-devel packages 
removed from 
/mnt/openmediavault/kernel/results/fedora-35-x86_64/goffice-0.10.50-2.fc35. 
If goffice or goffice-devel packages are present in the resultdir, an 
error will appear:
Error calculating checksum 
/mnt/openmediavault/kernel/results/fedora-35-x86_64/goffice-0.10.50-2.fc35/goffice-devel-0.10.50-2.fc35.x86_64.rpm: 
(39, fsync failed: Permission denied)

So, summing up:
- same host
- same target dir
- same build target
- effectively the same package [1]
- different outcome

The target dir is mounted on the samba server as:
/dev/sda1 on /srv/dev-disk-by-label-omv type ext4 
(rw,noexec,relatime,discard,stripe=8191,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group)

What could be causing this most bizarre behaviour?

Best regards,
Julian

[1] https://src.fedoraproject.org/rpms/goffice/commits/f35