Achim Gottinger
2023-Sep-08 10:08 UTC
[Samba] Access Problems after Update 4.13.13 to 4.17.10
Am 05.09.2023 um 18:12 schrieb Michael Tokarev:> 05.09.2023 15:55, Achim Gottinger via samba wrote: > ... >> I build samba 4.19 packages from debian unstable. Now the shares are empty and I can not create an file or folder inside. No error shown on the windows side but nothing happens if I create an folder >> or file in such an empty share. > > FWIW, binaries for 4.19 for usual share of debian/ubuntu systems > are available on my site at the usual place since yesterday. > It's not of help for you though, since basically it's the same > binaries you've got already rebuilding unstable pkgs. > >> Will backport the RDP patch to 4.13 now to get along. > > 4.13, while works in this context, is not supported anymore - neither > by samba team nor by debian. > > It'd be really interesting to see what the problem is.? Do you by > a chance has some symlinks inside your shares? > > But I've no ideas really, short of strace'ing some failing operations. > > /mjtThank 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. achim~
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