Michael Tokarev
2023-Sep-08 10:24 UTC
[Samba] Access Problems after Update 4.13.13 to 4.17.10
08.09.2023 13:08, Achim Gottinger via samba wrote: ..>> But I've no ideas really, short of strace'ing some failing operations. > > Thank you for the feedback! > Meanwhile I picked an snapshot of the oldest ad server (debian wheezy). I succesfully updated that vm to bullseye with samba from backports. This machine ist running as an xenserver vm with ext3 fs. > No access problems here. Same if i update to bookworm with samba from bookworm-backports. > This testing environment uses the same samba configuration and is part of the same ad domain as the one I tested earlier. > Narrows the issue down to beeing caused by systemd nspawn or zfs.It should work fine with both of these, but *might* need extra configuration. I know nothing about zfs. Speaking of nspawn, I had to use --capability=cap_ipc_lock for other things to work (which should not be related to samba at all). Current samba sure use modern system calls which didn't exist before, - even old nspawn might know nothing about them and hence block them. That's why I suggested using strace, it might reveal some failing syscalls. Can you try reducing the test case to a folder with a single file inside, which can't be accessed (or which is not returned when reading the dir), and maybe post the debug log from such attempt? (if you choose using strace, don't enable debugging in samba at the same time, as there will be just too much system calls for the debugging itself). /mjt
Achim Gottinger
2023-Sep-08 11:53 UTC
[Samba] Access Problems after Update 4.13.13 to 4.17.10
Am 08.09.2023 um 12:24 schrieb Michael Tokarev:> 08.09.2023 13:08, Achim Gottinger via samba wrote: > .. > >>> But I've no ideas really, short of strace'ing some failing operations. >> >> Thank you for the feedback! >> Meanwhile I picked an snapshot of the oldest ad server (debian wheezy). I succesfully updated that vm to bullseye with samba from backports. This machine ist running as an xenserver vm with ext3 fs. >> No access problems here. Same if i update to bookworm with samba from bookworm-backports. >> This testing environment uses the same samba configuration and is part of the same ad domain as the one I tested earlier. >> Narrows the issue down to beeing caused by systemd nspawn or zfs. > > It should work fine with both of these, but *might* need extra configuration. > > I know nothing about zfs. > > Speaking of nspawn, I had to use --capability=cap_ipc_lock for other things > to work (which should not be related to samba at all).? Current samba sure > use modern system calls which didn't exist before, - even old nspawn might > know nothing about them and hence block them. > > That's why I suggested using strace, it might reveal some failing syscalls. > > Can you try reducing the test case to a folder with a single file inside, > which can't be accessed (or which is not returned when reading the dir), > and maybe post the debug log from such attempt? > > (if you choose using strace, don't enable debugging in samba at the same > time, as there will be just too much system calls for the debugging > itself). > > /mjtThis is the strace log from the same test running with samba 4.13.