Got an odd one. Managed to solve it but I thought I’d post it here to help those who follow later.
The Problem
It seems as if Samba on my Truenas NAS (all of a sudden) is not taking account of POSIX user permissions on a share, but (oddly) group permissions are working.
The Truenas server is running SCALE 25.04.1.2 and I am connecting to the share using Windows 11.
I have an SMB share. Let’s call it “jon” mounted under /mnt/ZETAVOL/jon.
I connect to this share using a local user also called “jon” (UID 7003). jon’s primary group is GID 100, which has two entries in the groups file. “users” and “users_1”
All files and directories on the share are owned by jon:users (7003:100)
I can read and write files via the share if group permissions allow it, but not if user permissions allow it.
Example:
No problem accessing the following directory via the SMB share
drwxrwsr-x 21 jon users 30 May 9 09:58 "My PDFs"
Cannot click into the following directory however. Get an “Access denied - contact admin” message from Windows 11
drwx------ 367 jon users 368 Aug 17 13:30 SysPREP
If I ssh into the TrueNAS server as user jon, I can navigate to all directories, and create files there accordingly
jon@truenas:~$ touch /mnt/ZETAVOL/jon/SysPREP/test.txt
jon@truenas:~$ rm /mnt/ZETAVOL/jon/SysPREP/test.txt
Diagnostics
I initially thought that although I was presenting the correct credentials, somehow, I was being interpreted as a guest/nobody user. I disproved this with
smbstatus –processes
Samba version 4.21.7-truenas
PID Username Group …
----------------------- …
1070599 jon users …
This showed that the TrueNAS server had mapped me as the correct user, (“jon”).
Maybe ACLs are confusing the issue. I didn’t think I was using them but let’s see.
getfacl /mnt/ZETAVOL/jon/SysPREP
getfacl: Removing leading '/' from absolute path names
# file: mnt/ZETAVOL/jon/SysPREP
# owner: jon
# group: users
user::rwx
group::---
other::---
No NFSv4/ZFS ACL entries are shown - just the basic POSIX bits.
Maybe ZFS is not handling ACL inheritance properly on the dataset. Let’s have a look.
zfs get aclmode,aclinherit ZETAVOL/jon
NAME PROPERTY VALUE SOURCE
ZETAVOL/jon aclmode passthrough inherited from ZETAVOL
ZETAVOL/jon aclinherit passthrough inherited from ZETAVOL
Both modes set to “passthrough”. That’s the “normal” TrueNAS default. So …
- POSIX perms are passed through to the underlying ACL.
- New files inherit ACLs as-is.
Nothing here should force group bits to be honoured for the owner, and yet I am still experiencing the issue. Puzzling.
The only thing I can think of is that somehow sambas cache of the permissions has become corrupted.
I tried restarting the SMB service but that did not solve the issue. Maybe the cached permissions are saved and reloaded upon restart?
The solution
Stumbled upon almost by accident. I ran (as root)
net cache flush
(Samba provides an admin tool called “net”. Buried in the online manual was the above command.)
As soon as it was run the SysPREP folder became accessible via the share. Hooray!
I restarted the SMB service to see if the resolution would persist, but immediately the problem recurred. Hmmm.
Ran net cache flush again and the problem went away again. This time I waited 15 mins and then rebooted the TrueNAS server. The directory was still accessible after the reboot!
My Conclusion
Somehow Samba cache of the filesystem got screwy, leading it to not take account of POSIX user permissions properly
It can be fixed without downtime with net cache flush followed by a reboot when a suitable maintenance window presents.
In conclusion Samba’s caching of POSIX permissions caused the issue, and this points to a samba bug. For information the version of Samba being used was Version 4.21.7 (as determined by the smbstatus command used in the diagnostics above)
A Possible better fix?
The net cache flush command should not be run without caution. I have no doubt that it could cause performance issues on a production environment.
The problem might also be fixed by a simple reboot without running the above command. I really should have tried that first, but I can’t test that now without the problem being evident initially.
If others follow then maybe they can add some value to this post by testing if a simple reboot fixes things?