I’m a newby to Truenas and trying to move all my files from a PC P2P network onto Truenas CORE so that they are accessible 24/7.
I’m running Version: TrueNAS-13.0-U6.2 and it seems to be some kind of permissions problem as ,despite my user account being set up to Read, Write and Execute (Home Directory) everything, and SAMBA Authentication on
I can’t seem to run e.g. installer files in my Downloads folder on the NAS. But if I COPY the same installer file to my local PC (Win 10 Pro, 22H2, Build 19045, 5011) it works fine.
I have SMB 1.0 enabled (to access my old Netgear NAS drive which does not seem to be upgradeable) but would like to move away from that because of the security risks.
The error I get is “Windows cannot access
\TRUENAS\MyDrive\downloads\etc…
You do not have permission to access…
Contact your Administrator…” (I AM the Administrator!)
Have to say despite 40 years i IT I am not finding the terminology on TN to be that easy to follow!
(thought I could upload screenshots here but it says I cannot embed media items in a post???)
TIA
Andrew
I have run into the same issue, it seems tied only to exe files. I usually just do like your doing, copy them over to a temp folder and then execute them. I am pretty sure its part of the SMB way of transferring security, but I can’t be sure.
I juet posted the same question on. CHATGPT and it suggests you are correct. Setting permissions in SMB doesn’t affect the underlying permissions in ZFS file system used by TN.
You have four sets of settings to consider: dataset permissions, SMB permissions, filesystem ACLs, and client-side mount options. SMB permissions can never exceed the filesystem ACLs, at least on Scale.
If you haven’t already done so, make sure your dataset has the Exec(ute) option set to “on” and check your actual filesystem permissions in the web UI to make sure the dataset allows the user or group to execute files. You may also need to look at the actual filesystem to ensure the correct mode and xattr attributes are set.
It’s also possible that this is a client-side issue. I have no idea how you mounted the drive, but some systems may default to mounting network drives with “noexec” or similar. That would prevent the client from executing the file regardless of the server-side settings.
So, places to check:
Your dataset execute permissions.
Your SMB permissions.
Your share filesystem ACLs.
Your client mount options.
If it’s not one or more of those, turn on SMB audit logging and see if anything turns up. How (or if) you can debug this on the client side will be idiopathic, so I’m not sure what to recommend there since it’s outside the scope of what the server itself is doing.
That’s incorrect. Chatgpt often gives nonsense results. The SMB ACL is generated from the underlying ZFS ACL. Operations to set an SMB acl get converted into relevant OS APIs to set ZFS ACL. This is most likely a client-side issue (and a sensible security policy IMHO).
Thanks guys for your input. Following @CodeGnome suggestions I chased down the original file permissions on the PC where they came from. It seems the Full permissions get changed when the files are uploaded (by Copy/Paste) to TrueNAS so I no longer have access to my own executables in my Downloads folder.
I don’t know if there is an easy way to reset these permissions in TrueNAS?
I’m afraid I have had to give up on TrueNAS and revert to a simple solution using Samba.
It just lost around 500GB of files in two big folders that are no longer visible. But the disk capacity is still down by that amount!
If you have in fact ditched TrueNAS, this will be useless to you. But, I encountered the same permissions problem when trying to open .exe files in W10/11 from my SMB share on TrueNAS. There is a “solution” posted in the old (now read-only) TrueNAS forum (I think). Could NOT find it just now, however. It advises going into the Advanced options menu to edit your TN SMB share.
Under “Auxillary Parameters” (bottom of Right Column) enter:
acl allow execute always=yes
Save this and you should be able to open executable files in Windows from your TN SMB share.
CAVEAT: there’s not that much out there about using “acl allow execute always=yes” and it may NOT be the best/correct approach. One site (didn’t find it just now, either) indicated it to be a “temporary” work-around until…well, until anyone knows when. So, assume this approach may entail vulnerabilities (to me, for sure) of unknown nature and unknown severity.
Maybe SOMEONE who knows the ins and outs of this matter AND the implications of using “acl allow execute always=yes” as described will jump in and reduce our collective ignorance.
/*
* Samba 3.6 and earlier granted execute access even
* if the ACL did not contain execute rights.
* Samba 4.0 is more correct and checks it.
* The compatibility mode allows one to skip this check
* to smoothen upgrades.
*/
if (lp_acl_allow_execute_always(SNUM(fsp->conn))) {
do_not_check_mask |= FILE_EXECUTE;
}
status = smbd_check_access_rights_fname(fsp->conn,
fsp->fsp_name,
use_privs,
access_mask,
do_not_check_mask);
if (!NT_STATUS_EQUAL(status, NT_STATUS_MORE_PROCESSING_REQUIRED)) {
return status;
}
All allow_execute_always does is prevent access checks for FILE_EXECUTE. If you simply grant your users these rights, then there’s no need to hard-code execute rights.
