Trying to access files on Samba 4.20 shares resulting in "No such file or directory"

J

jem

A couple of days ago I upgraded the Samba package on my FreeBSD NAS from 4.19 to 4.20. I didn't test access to shares right away, but today I noticed that scheduled backups of my Fedora laptop to one of the Samba shares had failed.

It appeared that the share had mounted OK, the directory where the backups were saved was accessible, and all previous backup files were visible in there. However the backup utility logs were showing a "No such file or directory" when trying to open the manifest file of last week's successful backup, but it was plainly there and had correct permissions to access. I tried 'cat'ing the file in a bash shell and got the same error. 'stat'ing the file worked and 'getfacl' returned sane ACL entries.

I logged onto the FreeBSD NAS and was able to access the file just fine. There were no errors in /var/log/messages or any of the samba log files.

I booted my laptop into Windows 11 and tried accessing the file, but got an error about the file not existing (having just double-clicked it in File Explorer) and asking if I wanted to create it. Trying to access any other file on any other share also returned similar errors.

I downgraded Samba back to 4.19 and everything started working again.

It looks like the samba420 package has a problem and I'm going to file a report for it, but I wanted to check whether anyone else has encountered the same thing
 
Yes there's some issue with the samba420-4.20.7_1 from the latest pkg.
When i try to create or save a file from Win11 client it crash.
I may try to build it from ports to see if it's the same.

smb4.conf
[global]
server role = standalone
preferred master = no

[public]
path = /share/public
read only = no
Click to expand...


Feb 21 09:03:33 btest smbd[7309]: [2025/02/21 09:03:33.453968, 0] ../../lib/util/fault.c:304(log_stack_trace)
Feb 21 09:03:33 btest smbd[7309]: BACKTRACE: 20 stack frames:
Feb 21 09:03:33 btest smbd[7309]: #0 0xe49e3e2cec7 <log_stack_trace+0x37> at /usr/local/lib/samba4/private/libgenrand-private-samba.so
Feb 21 09:03:33 btest smbd[7309]: #1 0xe49e3e2cf9e <smb_panic+0xe> at /usr/local/lib/samba4/private/libgenrand-private-samba.so
Feb 21 09:03:33 btest smbd[7309]: #2 0xe49d9316324 <smbd_exit_server+0x1b4> at /usr/local/lib/samba4/private/libsmbd-base-private-samba.so
Feb 21 09:03:33 btest smbd[7309]: #3 0xe49d9316181 <smbd_exit_server+0x11> at /usr/local/lib/samba4/private/libsmbd-base-private-samba.so
Feb 21 09:03:33 btest smbd[7309]: #4 0xe49e3854bcc <exit_server+0x1c> at /usr/local/lib/samba4/private/libsmbd-shim-private-samba.so
Feb 21 09:03:33 btest smbd[7309]: #5 0xe49d92c1300 <delete_all_streams> at /usr/local/lib/samba4/private/libsmbd-base-private-samba.so
Feb 21 09:03:33 btest smbd[7309]: #6 0xe49e5470dff <tevent_common_invoke_timer_handler+0x18f> at /usr/local/lib/libtevent.so.0
Feb 21 09:03:33 btest smbd[7309]: #7 0xe49e5470fa4 <tevent_common_loop_timer_delay+0x94> at /usr/local/lib/libtevent.so.0
Feb 21 09:03:33 btest smbd[7309]: #8 0xe49e546e7c5 <tevent_context_same_loop+0xb15> at /usr/local/lib/libtevent.so.0
Feb 21 09:03:33 btest smbd[7309]: #9 0xe49e546a36a <_tevent_loop_once+0xea> at /usr/local/lib/libtevent.so.0
Feb 21 09:03:33 btest smbd[7309]: #10 0xe49e546a5f2 <tevent_common_loop_wait+0x32> at /usr/local/lib/libtevent.so.0
Feb 21 09:03:33 btest smbd[7309]: #11 0xe49d92dbb4b <smbd_process+0x83b> at /usr/local/lib/samba4/private/libsmbd-base-private-samba.so
Feb 21 09:03:33 btest smbd[7309]: #12 0xe41b7f32aad <main+0x436d> at /usr/local/sbin/smbd
Feb 21 09:03:33 btest smbd[7309]: #13 0xe49e546b67e <tevent_common_invoke_fd_handler+0x9e> at /usr/local/lib/libtevent.so.0
Feb 21 09:03:33 btest smbd[7309]: #14 0xe49e546ea44 <tevent_context_same_loop+0xd94> at /usr/local/lib/libtevent.so.0
Feb 21 09:03:33 btest smbd[7309]: #15 0xe49e546a36a <_tevent_loop_once+0xea> at /usr/local/lib/libtevent.so.0
Feb 21 09:03:33 btest smbd[7309]: #16 0xe49e546a5f2 <tevent_common_loop_wait+0x32> at /usr/local/lib/libtevent.so.0
Feb 21 09:03:33 btest smbd[7309]: #17 0xe41b7f3102f <main+0x28ef> at /usr/local/sbin/smbd
Feb 21 09:03:33 btest smbd[7309]: #18 0xe41b7f2fc2c <main+0x14ec> at /usr/local/sbin/smbd
Feb 21 09:03:33 btest smbd[7309]: #19 0xe49e6a05c3a <__libc_start1+0x12a> at /lib/libc.so.7
Click to expand...
 
I see the same issue here on Linux clients and one Windows client. All files are visible but attempting to read them or create a file results in "No such file or directory" errors. All the recently touched logs in /var/log/samba4 show nothing amiss. Downgrading to samba419 immediately fixes the problem.

Almost a month on this with no response?
 
I was seeing the same problem on the weekend too. I am in the middle of upgrading my home server hardware and re-installing everything. I spent hours trying to figure it out before I clued in that there is this /var/log directory that store all the ugly details. Sure enough there's something wrong with samba420 right now.

I went back to samba416, the one running on my old system, and it's all good.
 
I had similar problem with 4.20.7 from packages. Because the log file suggested, I had added

Code: 
vfs objects = zfsacl

which resulted in NT_STATUS_OBJECT_NAME_NOT_FOUND for any file. The SAMBA log shows "read=No" for the file read requests.

reverting to 4.19 with the same setup worked properly, with "read=Yes" in the log. Removing this configuration, 4.20 runs properly too.

Apparently there is need for additional ZFS ACL configuration on the shares, which I didn't bother doing.
 
danbi said:
I had similar problem with 4.20.7 from packages. Because the log file suggested, I had added

Code: 
vfs objects = zfsacl

which resulted in NT_STATUS_OBJECT_NAME_NOT_FOUND for any file. The SAMBA log shows "read=No" for the file read requests.

reverting to 4.19 with the same setup worked properly, with "read=Yes" in the log. Removing this configuration, 4.20 runs properly too.

Apparently there is need for additional ZFS ACL configuration on the shares, which I didn't bother doing.
Click to expand...
What log level did you have to set to see those error messages?

I have:

Code: 
   vfs objects = zfsacl
   nfs4:acedup = merge
   nfs4:chown = no
   zfsacl:map_dacl_protected=yes

Do they have to be set on a per-share basis?
 
You must log in or register to reply here.
Back
Top