This’ll be a long read, and it’s going to get quite tricky, but it’s necessary to provide all this information for the rather exhaustive testing I’ve done.
I have a problem. I couldn’t copy files into some directories in my share. After trying to fix this, I now can’t copy files into all directories inside said share. (Something I did caused this change. Unfortunately I don’t know what.) This only applies on the Windows side of things. On linux, copying in files or making new files (touch, etc.) works.
It could be related that the NAS was briefly inside the domain as a test. I’ve since removed it.
The ZFS filesystem is not readonly. Permissions for the user are set to rwx. Doesn’t matter if I use unix permissions, POSIX ACLs, or NFSv4 ACLs. The result is the same. POSIX attributes are empty (no readonly bit set). I checked for anything related to samba or filesystems in apparmor, nothing. SELinux is afaik nonexistent in Truenas Scale, so that can’t be it either.
Either way, if I do
sudo -u veritas echo "hello world" > /mnt/tank/zroot/backups/SDR/testfile.txt
this works. I can surmise on the UNIX side of things as far as TrueNAS is concerned my user has permission to write into that directory. SMB is failing to correctly communicate this to a Windows server 2022 that’s trying to also write files there.
Yet on windows: I can write, but not read.
Moving on to Samba, which is the most likely culprit:
Here’s the output of testparm -s as of now (it’s changed a bunch from experimenting with settings):
Server role: ROLE_STANDALONE
# Global parameters
[global]
bind interfaces only = Yes
disable spoolss = Yes
dns proxy = No
load printers = No
logging = file
max log size = 5120
netbios name = TRUENAS
passdb backend = tdbsam:/var/run/samba-cache/private/passdb.tdb
printcap name = /dev/null
registry shares = Yes
restrict anonymous = 2
server multi channel support = No
server string = TrueNAS Server
username map = /etc/samba/user.map
winbind request timeout = 2
workgroup = ACME
idmap config * : range = 90000001 - 100000000
fruit:nfs_aces = false
fruit:zero_file_id = false
rpc_server:mdssvc = disabled
rpc_daemon:mdssd = disabled
idmap config * : backend = tdb
create mask = 0775
directory mask = 0775
[backups_veritas]
ea support = No
force group = veritas
force user = veritas
inherit acls = Yes
map acl inherit = Yes
path = /mnt/tank/zroot/backups
posix locking = No
read only = No
smbd max xattr size = 2097152
vfs objects = truenas_audit streams_xattr acl_xattr zfs_core io_uring
write list = veritas
tn:vuid =
fruit:time machine max size = 0
fruit:time machine = False
tn:home = False
tn:path_suffix =
tn:purpose = NO_PRESET
I’ve used samba-regedit to add a bunch more things that make it less likely something in smb is making things readonly, just for testing purposes. I’ve added force group, explicit read only, explicit writable, write list, tried changing the value of vfs objects to remove the ACL thing, all to no avail.
I bumped the log level all the way to 4, to see what was happening in detail as I copied in a file (nothing else is using this share outside of the backup, so I can follow along what’s happening with tail -f /var/log/user.log)
Doing that informed me that samba was setting the UID to 4000 (veritas): I see a lot of messages such as
../../source3/smbd/sec_ctx.c:206(push_sec_ctx) push_sec_ctx(4000, 4000) : sec_ctx_stack_ndx = 1
I then used samba-tool to check the NTFS-ACL hidden in the file attributes. First, I have to create a temporary backup config file to export the running configuration into as samba-tool won’t read the smb registry for the settings:
testparm -s > /etc/samba/smb.conf.bak
env SMB_CONF_PATH=/etc/samba/smb.conf.bak samba-tool ntacl get --as-sddl SDR
O:S-1-5-21-3950464277-3008394869-184636553-20067G:S-1-22-2-4000D:P(A;OICI;FA;;;S-1-5-21-3950464277-3008394869-184636553-20067)(A;OICI;FA;;;S-1-22-2-4000)(A;OICI;;;;WD)(A;;FA;;;S-1-22-2-4000)(A;;FA;;;S-1-5-21-3950464277-3008394869-184636553-20067)(A;OICIIO;FA;;;CO)(A;OICIIO;FA;;;CG)
Note the ‘Full Access’. I can even view (and edit!) these permissions from windows as the domain admin. Note that the Truenas is not in the domain (I don’t want it to be. I don’t want the domain admin to be mapped to root so it can remove ZFS snapshots when the cryptolocker skids sneak in). I can’t copy in a file though, so it seems like they have no effect on what samba’s allowing.
To check that the SIDs are correct:
wbinfo -s S-1-5-21-3950464277-3008394869-184636553-20067
produced TRUENAS\veritas. S-1-22-2-4000 is Unix Group\veritas
I’m mounting the share using the following shell code on windows:
net use \\nas-01_acme_com\backups_veritas $password /user:TRUENAS\veritas
Where password is the SMB user’s password, which is identical to the linux user password and the windows user password, a 16+ length password using only a-zA-Z0-9 and a single plus symbol. I don’t expect that to matter as a password communication failure should mean no connectivity at all. Note that connecting as ACME\veritas or WORKGROUP\veritas has the same result (can’t copy files).
One other thing: If
net use \\nas-01_acme_com\backups_veritas /user:TRUENAS\veritas
is passed instead, I can still connect. (This isn’t intended, I want to require the password so only the backup server can make this connection)
I dug even further and checked the DOSATTR structure, coming to the conclusion that this is unlikely to be an issue at all, but it does point to something interesting. Checking the value on the linux side, I can see this:
env SMB_CONF_PATH=/etc/samba/smb.conf.bak samba-tool ntacl getdosinfo /mnt/tank/zroot/backups/SDR
xattr_DOSATTRIB: struct xattr_DOSATTRIB
attrib_hex : ''
version : 0x0005 (5)
info : union xattr_DosInfo(case 5)
info5: struct xattr_DosInfo5
valid_flags : 0x00000011 (17)
1: XATTR_DOSINFO_ATTRIB
0: XATTR_DOSINFO_EA_SIZE
0: XATTR_DOSINFO_SIZE
0: XATTR_DOSINFO_ALLOC_SIZE
1: XATTR_DOSINFO_CREATE_TIME
0: XATTR_DOSINFO_CHANGE_TIME
0: XATTR_DOSINFO_ITIME
attrib : 0x00000010 (16)
create_time : Tue Jun 4 20:43:31 2024 CEST
I check the same value on windows. If I check it using Powershell, I get:
Get-ItemProperty -Path SDR | Format-List -Property * -Force
(irrellevant output removed)
Attributes: Directory.
But if I check using the File Explorer, the Readonly box is checked.
Yes, this means Powershell and Explorer disagree about whether or not the directory is Read Only for DOS. Not that this should matter; this attribute is legacy and no longer respected afaict. Testing it out on a random windows folder; if set you can still write/copy/create files just fine.
But it’s interesting information to do a little test with. On a hunch I tried changing this value on the unix side to 0x00000500050000001000000010000000e8567218afb6da01 instead.
It had no effect on the windows side. Explorer still posits it’s read only. I still can’t copy files.
I’ve tried to re-set the password to the same value using smbpasswd veritas, no effect.
Q: What else could it be?
P.S.: Your new forum’s code box function is a bit broken: it removes all \r\n from the text smushing it into a single unreadable line.
P.P.S. PII redacted.