Julian Sikorski
2021-Sep-28 17:38 UTC
[Samba] Permission denied when chainbuilding packages with mock
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
Julian Sikorski
2021-Nov-04 19:16 UTC
[Samba] Permission denied when chainbuilding packages with mock
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