[Samba] Access Problems after Update 4.13.13 to 4.17.10

Achim Gottinger achim at ag-web.biz
Fri Sep 8 12:18:20 UTC 2023



Am 08.09.2023 um 13:53 schrieb Achim Gottinger:
>
> 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.
First strace.log file is to big for the list. Here is my text:

For further testing I setup an small nspawn vm with samba as an domain member fileserver.
Same here with 4.17 from bullseye-backports only the first hierarchy of folders is accessible.
I did an strace while trying to enter an subfolder and attached it here. (from /data/data/Neuer Ordner to /data/data/Neuer Ordner/Neuer Ordner)

Restarted the vm with --capability=all but the error remains.

Attaching the strace logfile. It is only an test environment.

The host system for the nspawn containers is running on debian buster atm.


Comparing the two log files the first thing is see is the openat2 call which was openat with 4.13

4.17:

chdir("/data/data")                     = 0
stat(".", {st_mode=S_IFDIR|0777, st_size=3, ...}) = 0
stat("/data/data", {st_mode=S_IFDIR|0777, st_size=3, ...}) = 0
openat2(AT_FDCWD, "Neuer Ordner", {flags=O_RDONLY|O_NOFOLLOW|O_PATH|O_DIRECTORY, resolve=RESOLVE_NO_SYMLINKS}, 24) = -1 EPERM (Die Operation ist nicht erlaubt)
sendmsg(35, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0I", iov_len=4}, {iov_base=NULL, iov_len=0}, {iov_base="\376SMB@\0\1\0\"\0\0\300\5\0\1\0001\0\0\0\0\0\0\0;\0\0\0\0\0\0\0"..., iov_len=64}, {iov_base="\t\0\0\0\0\0\0\0", iov_len=8}, {iov_base="\0", iov_len=1}], msg_iovlen=5, msg_controllen=0, msg_flags=0}, 0) = 77
gettimeofday({tv_sec=1694171946, tv_usec=893684}, NULL) = 0
epoll_wait(5, [{EPOLLIN, {u32=2896432192, u64=94835774327872}}], 1, 759) = 1

4.13:
chdir("/data/data")                     = 0
stat(".", {st_mode=S_IFDIR|0777, st_size=3, ...}) = 0
stat("/data/data", {st_mode=S_IFDIR|0777, st_size=3, ...}) = 0
stat(".", {st_mode=S_IFDIR|0777, st_size=3, ...}) = 0
getcwd("/data/data", 4096)              = 11
gettimeofday({tv_sec=1694173720, tv_usec=159095}, NULL) = 0
getxattr(".", "user.DOSATTRIB", 0x7ffc043bcb30, 256) = -1 ENODATA (Keine Daten verfügbar)
stat(".", {st_mode=S_IFDIR|0777, st_size=3, ...}) = 0
getxattr(".", "system.posix_acl_access", 0x7ffc043bc950, 132) = -1 ENODATA (Keine Daten verfügbar)
stat(".", {st_mode=S_IFDIR|0777, st_size=3, ...}) = 0
getxattr(".", "system.posix_acl_default", 0x7ffc043bc950, 132) = -1 ENODATA (Keine Daten verfügbar)
stat(".", {st_mode=S_IFDIR|0777, st_size=3, ...}) = 0
fcntl(27, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=36508, l_len=1}) = 0
fcntl(27, F_SETLKW, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=36508, l_len=1}) = 0
stat(".", {st_mode=S_IFDIR|0777, st_size=3, ...}) = 0
getxattr(".", "system.posix_acl_access", 0x7ffc043bc910, 132) = -1 ENODATA (Keine Daten verfügbar)
stat(".", {st_mode=S_IFDIR|0777, st_size=3, ...}) = 0
getxattr(".", "system.posix_acl_default", 0x7ffc043bc910, 132) = -1 ENODATA (Keine Daten verfügbar)
stat(".", {st_mode=S_IFDIR|0777, st_size=3, ...}) = 0
gettimeofday({tv_sec=1694173720, tv_usec=164763}, NULL) = 0
stat(".", {st_mode=S_IFDIR|0777, st_size=3, ...}) = 0
stat("/data/data", {st_mode=S_IFDIR|0777, st_size=3, ...}) = 0
getcwd("/data/data", 4096)              = 11
openat(AT_FDCWD, ".", O_RDONLY|O_NOFOLLOW|O_DIRECTORY) = 8

Which lead to this bug report
https://github.com/containers/crun/issues/545 Fallback from openat2 to openat under systemd-nspawn

I tried the workaround mentioned and ran the container with " --capability=all --system-call-filter=openat2". Unfortunately I get the same error.





More information about the samba mailing list