[Samba] Access Problems after Update 4.13.13 to 4.17.10

Achim Gottinger achim at ag-web.biz
Fri Sep 8 11:53:45 UTC 2023

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).
> /mjt
This is the strace log from the same test running with samba 4.13.

More information about the samba mailing list