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?
 
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...

Aparently the problem is not yet resolved. After upgrading from 4.19 to 4.20(.7_4) last week, I received:

Code: 
 Error loading module '/usr/local/lib/samba4/modules/vfs/zfsacl.so': /usr/local/lib/samba4/private/libsmbd-base-samba4.so: version SAMBA_4.19.6_SAMBA4 required by /usr/local/lib/samba4/modules/vfs/zfsacl.so not found

Commenting out the vdefs.objects line worked for me as well.
 
I'm still experiencing an issue.


I tried a fresh install of FreeBSD 14.2 with a fresh install (not an upgrade) of Samba 4.20 on a test system (FreeBSD version: samba420-4.20.7_4), and I am seeing similar results for the attempted (and now have backtracked on the main Samba server here) upgrade of Samba from 4.19 to 4.20 on a data server.

Under 4.20 I was able to create a new directory on a Samba share on both Windows and Linux Mint clients.

But when i tried to create a new file in that directory, the client times out because of no response from the server.

The log shows ...

May 31 17:27:56 t04 smbd[75610]: Copyright Andrew Tridgell and the Samba Team 1992-2024
May 31 17:27:57 t04 root[86487]: ===> begin /usr/local/sbin/run-at-startup.sh **************
May 31 17:27:57 t04 root[94620]: ===> end /usr/local/sbin/run-at-startup.sh **************
May 31 17:32:46 t04 smbd[9632]: [2025/05/31 17:32:46.083806, 0] ../../lib/util/fault.c:178(smb_panic_log)
May 31 17:32:46 t04 smbd[9632]: ===============================================================
May 31 17:32:46 t04 smbd[9632]: [2025/05/31 17:32:46.407565, 0] ../../lib/util/fault.c:185(smb_panic_log)
May 31 17:32:46 t04 smbd[9632]: INTERNAL ERROR: async open timeout in smbd () (client [10.11.2.85]) pid 9632 (4.20.7)
May 31 17:32:46 t04 smbd[9632]: [2025/05/31 17:32:46.407817, 0] ../../lib/util/fault.c:190(smb_panic_log)
May 31 17:32:46 t04 smbd[9632]: If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, plea
se consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting
May 31 17:32:46 t04 smbd[9632]: [2025/05/31 17:32:46.407987, 0] ../../lib/util/fault.c:191(smb_panic_log)
May 31 17:32:46 t04 smbd[9632]: ===============================================================
May 31 17:32:46 t04 smbd[9632]: [2025/05/31 17:32:46.408114, 0] ../../lib/util/fault.c:193(smb_panic_log)
May 31 17:32:46 t04 smbd[9632]: PANIC (pid 9632): async open timeout in 4.20.7
May 31 17:32:46 t04 smbd[9632]: [2025/05/31 17:32:46.418917, 0] ../../lib/util/fault.c:304(log_stack_trace)
May 31 17:32:46 t04 smbd[9632]: BACKTRACE: 20 stack frames:
May 31 17:32:46 t04 smbd[9632]: #0 0xf2963c7cec7 <log_stack_trace+0x37> at /usr/local/lib/samba4/private/libgenrand-private-samba.so
May 31 17:32:46 t04 smbd[9632]: #1 0xf2963c7cf9e <smb_panic+0xe> at /usr/local/lib/samba4/private/libgenrand-private-samba.so
May 31 17:32:46 t04 smbd[9632]: #2 0xf295ad56324 <smbd_exit_server+0x1b4> at /usr/local/lib/samba4/private/libsmbd-base-private-samba.so
May 31 17:32:46 t04 smbd[9632]: #3 0xf295ad56181 <smbd_exit_server+0x11> at /usr/local/lib/samba4/private/libsmbd-base-private-samba.so
May 31 17:32:46 t04 smbd[9632]: #4 0xf2964eb8bcc <exit_server+0x1c> at /usr/local/lib/samba4/private/libsmbd-shim-private-samba.so
May 31 17:32:46 t04 smbd[9632]: #5 0xf295ad01300 <delete_all_streams> at /usr/local/lib/samba4/private/libsmbd-base-private-samba.so
May 31 17:32:46 t04 smbd[9632]: #6 0xf2965e32dff <tevent_common_invoke_timer_handler+0x18f> at /usr/local/lib/libtevent.so.0
May 31 17:32:46 t04 smbd[9632]: #7 0xf2965e32fa4 <tevent_common_loop_timer_delay+0x94> at /usr/local/lib/libtevent.so.0
May 31 17:32:46 t04 smbd[9632]: #8 0xf2965e307c5 <tevent_context_same_loop+0xb15> at /usr/local/lib/libtevent.so.0
May 31 17:32:46 t04 smbd[9632]: #9 0xf2965e2c36a <_tevent_loop_once+0xea> at /usr/local/lib/libtevent.so.0
May 31 17:32:46 t04 smbd[9632]: #10 0xf2965e2c5f2 <tevent_common_loop_wait+0x32> at /usr/local/lib/libtevent.so.0
May 31 17:32:46 t04 smbd[9632]: #11 0xf295ad1bb4b <smbd_process+0x83b> at /usr/local/lib/samba4/private/libsmbd-base-private-samba.so
May 31 17:32:46 t04 smbd[9632]: #12 0xf213845caad <main+0x436d> at /usr/local/sbin/smbd
May 31 17:32:46 t04 smbd[9632]: #13 0xf2965e2d67e <tevent_common_invoke_fd_handler+0x9e> at /usr/local/lib/libtevent.so.0
May 31 17:32:46 t04 smbd[9632]: #14 0xf2965e30a44 <tevent_context_same_loop+0xd94> at /usr/local/lib/libtevent.so.0
May 31 17:32:46 t04 smbd[9632]: #15 0xf2965e2c36a <_tevent_loop_once+0xea> at /usr/local/lib/libtevent.so.0
May 31 17:32:46 t04 smbd[9632]: #16 0xf2965e2c5f2 <tevent_common_loop_wait+0x32> at /usr/local/lib/libtevent.so.0
May 31 17:32:46 t04 smbd[9632]: #17 0xf213845b02f <main+0x28ef> at /usr/local/sbin/smbd
May 31 17:32:46 t04 smbd[9632]: #18 0xf2138459c2c <main+0x14ec> at /usr/local/sbin/smbd
May 31 17:32:46 t04 smbd[9632]: #19 0xf29684ffc3a <__libc_start1+0x12a> at /lib/libc.so.7
Click to expand...
 
And, if I may be so bold to add ...

How did this get by the QA process for this, imo, most important port?

This behavior seems to be so unlike the behavior of FreeBSD that I have come to know over the decades.

And, more importantly, what procedures will be put in place to prevent a similar occurrence in the future?
 
I was experiencing this with samba420-4.20.7_4. Brief testing with samba420-4.20.7_5 from the latest repo indicates the async timeout bug has been resolved.
 
onerider said:
I was experiencing this with samba420-4.20.7_4. Brief testing with samba420-4.20.7_5 from the latest repo indicates the async timeout bug has been resolved.
Click to expand...

Thanks for the heads up. I see that samba420 was updated to samba420-4.20.7_5 on June 11.

I did some quick testing on a test server here, and the problem I had been seeing no longer presents itself. It looks like the issue has been fixed.

Major thank-you to those who worked to fix this problem.
 
As I previously said, major thanks for the patch.

But I have to ask ...

Is the patch a FreeBSD-specific thing?

If so, why?

If not, will the patch be reflected in future Samba releases so that the good FreeBSD folk do not have to clean up the Samba code so that it works on FreeBSD?

thx.
 
Just chiming in that I just hit this issue too. I'm on 14.2-RELEASE-p3. Ran pkg update/upgrade and then removed samba416, followed by install of samba420. Looks like the latest available version is still 4.20.7_4? Retried pkg update/upgrade, no avail.
% pkg info samba420
samba420-4.20.7_4
Name : samba420
Version : 4.20.7_4
Installed on : Fri Jun 27 09:03:38 2025 AEST
Origin : net/samba420
Architecture : FreeBSD:14:amd64
Click to expand...
Think I'll remove and install samba419 so I can get on with my work day.
 
Same problem here. I'm still on 13.5-RELEASE and updating to Samba 4.20.7_5 didn't solve it for me. Edit: Reverted back to samba419. All is well :-)
 
theriverlethe said:
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?
Click to expand...
I've had various issues with timeouts in Nautilus (Ubuntu, openSUSE, Fedora) and Thunar FreeBSD this year copy to and transfers. It was usually on a 14GB+ zip, but I've seen it randomly on folders with a bunch of smaller files. I have a right-click folder share from Windows 10 21H2 and 11 24H2.

I haven't looked into it, and re-transfers work most of the time.
 
If this helps anyone, looks like the problem's here on samba4.20-4.20.7_7 (on 14.2R) when trying to read a file:

Code: 
83141: openat(15,"foo.txt",O_RDONLY|O_NOFOLLOW|O_PATH,00) = 29 (0x1d)
83141: fstat(29,{ mode=-rwxr--r-- ,inode=3474,size=11166105,blksize=131072 }) = 0 (0x0)
...
83141: extattr_get_file(""/compat/linux/dev/fd/"29",EXTATTR_NAMESPACE_USER,"DOSATTRIB",0x0,0) ERR#2 'No such file or directory'
83141: __acl_get_file(""/compat/linux/dev/fd/"29",ACL_TYPE_NFS4,0x3cbb57cec000) ERR#2 'No such file or directory'
83141: close(29)                                 = 0 (0x0)
83141: sendmsg(34,{NULL,0,[{"\0\0\0I",4},{0x0,0},{"\M-~SMB@\0\^A\0004\0\0\M-@\^E\0"...,64},{"\t\0\0\0\0\0\0\0",8},{"\0",1}],5,{},0,0},MSG_DONTWAIT|MSG_NOSIGNAL) = 77 (0x4d)
83141: close(15)                                 = 0 (0x0)

Which is all kinds of wrong (no linux compat here, and what's going on with the filename quoting?)

On 4.19.9_9 the working behaviour is this:
Code: 
85454: openat(30,"bar.txt",O_RDONLY|O_NOFOLLOW|O_PATH,00) = 31 (0x1f)
85454: fstat(31,{ mode=-rwxr--r-- ,inode=2478,size=11061359,blksize=131072 }) = 0 (0x0)
...
85454: extattr_get_file("/var/run/samba4/fd/31",EXTATTR_NAMESPACE_USER,"DOSATTRIB",0x0,0) = 32 (0x20)
85454: extattr_get_file("/var/run/samba4/fd/31",EXTATTR_NAMESPACE_USER,"DOSATTRIB","\0\0\^D\0\^D\0\0\0Q\0\0\0 \0\0\0"...,256) = 32 (0x20)
85454: __acl_get_file("/var/run/samba4/fd/31",ACL_TYPE_NFS4,0x5412114dc000) = 0 (0x0)
85454: __acl_get_file("/var/run/samba4/fd/31",ACL_TYPE_NFS4,0x5412114e2000) = 0 (0x0)
 
I have a installation of freebsd 14.2 with samba420 with AD,

I can access the shares on localhost using the Domain username and password. also the same on another freebsd 14.2 with thunar , but unable to access from windows 11 , weirdly on the windows 11 i can access only the data share using the domain administrator name. The windows 11 is connected to AD from samba420.

here are my smb4.conf
[global]
#binddns dir = /usr/local/samba4/bind-dns
cache directory = /usr/local/samba4/cache
dns forwarder = 8.8.8.8
interfaces = genet0 lo
lock directory = /usr/local/samba4
netbios name = SAYWAT-PI
private dir = /usr/local/samba4/private
realm = DOMAIN.HOME
server max protocol = SMB3
server min protocol = SMB2
#server smb encrypt = required
#smb encrypt = required
log level = 2
max log size = 5000
server role = active directory domain controller
server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dns, dnsupdate
state directory = /usr/local/samba4/state
winbind enum groups = Yes
winbind enum users = Yes
winbind nss info = rfc2307
winbind use default domain = Yes
workgroup = DOMAIN
idmap_ldb:use rfc2307 = yes
idmap config domain : range = 10000-999999
idmap config domain : schema_mode = rfc2307
idmap config domain : backend = ad
idmap config * : range = 1000-9999
idmap config * : backend = tdb
ea support = Yes
map acl inherit = Yes
nt acl support = Yes
store dos attributes = Yes
vfs objects = acl_xattr # Comment out if not needed or unsupported

[sysvol]
path = /usr/local/samba4/state/sysvol
read only = No
valid users = "DOMAIN\administrator" "DOMAIN\user1"
vfs objects = acl_xattr
acl_xattr:ignore system acls = yes
xattr_tdb:file = /usr/local/samba4/state/xattr.tdb
[netlogon]
path = /usr/local/samba4/state/sysvol/saywat.home/scripts
read only = No
valid users = "DOMAIN\administrator" "DOMAIN\user1"
vfs objects = acl_xattr
acl_xattr:ignore system acls = yes
xattr_tdb:file = /usr/local/samba4/state/xattr.tdb

[data]
path = /path/to/data
read only = No
browsable = Yes
valid users = "DOMAIN\administrator" "DOMAIN\user1"
vfs objects = zfsacl
nt acl support = Yes
map acl inherit = Yes
store dos attributes = Yes
#smb encrypt = required

Any ideas?
 
You must log in or register to reply here.
Back
Top