Execute bit on files and directories created via SMB share

[EnforcerMP]

Hello everyone,

I am trying to build a TrueNAS Scale server for home use (so no Active Directory or LDAP issues to worry about in this context), and I'm using Cobia (version 23.10.1.1, to be exact). Both Linux and Windows machines need to be able to access the files, so this pretty much forces me to use SMB shares. However, I am encountering an issue regarding permissions.

If I am not mistaken, the following is standard practice in the Unix permission world:

• Directories need to have (at least) the execute bit set if the files they contain are to be accessible in any way
• On the other hand, files should only have the execute bit set if they are actually executable files

I have been trying to reproduce this on TrueNAS Scale, but it seems that no matter what ACL type I select (POSIX or NFS), or how I configure the ACL, whenever I try to create files or directories via the SMB share, one of two things happen:

• Both files and directories have their execute bit set, which means that files that are not actually executable (such as office documents, pictures, audio files, and videos) can be executed as programs
• Neither files or directories have their execute bit set, which means that I cannot access directories that I create

After a bit of online searching, I found the following thread by bmarino, which describes a problem similar to mine:

https://www.truenas.com/community/threads/smb-permissions-on-newly-created-files.101774/​

I tried to perform the steps mentioned in this thread (which involve using auxiliary share parameters to set the create mask), but I ran into a few issues:

1. To the best of my knowledge, the use of auxiliary parameters seems discouraged unless strictly necessary
2. Perhaps as a way to illustrate (1), the auxiliary parameters field has been removed from both the share configuration and the SMB service configuration screen
3. Trying to set the create mask using either the CLI or the File Mask field in the Advanced Settings section of the SMB service configuration screen does not seem to work (its default value is 0666 which should accomplish what I want, but it seems to be ignored when I create a file via the share).

Does someone know a procedure I could follow to configure a TrueNAS Scale server so that when I create files and directories via an SMB share, directories get their execute bit set but not files?

Thank you for your consideration.

 

[ABain]

Both Linux and Windows machines need to be able to access the files, so this pretty much forces me to use SMB shares.

In Cobia you do have the option to add multiprotocol shares: https://www.truenas.com/docs/scale/23.10/scaletutorials/shares/mixedmodeshares/

 

[RandomPrecision]

I have struggled with this quite a bit, though I'm not sure if my use-case is the same as yours: are you trying to use Samba for both Linux and Windows, or NFS for Linux and Samba for Windows? If the latter, I have it mostly working, see this: Home directory share - NFS and SMB - How to set ACL correctly?. By "mostly" working, what I mean is that permissions on both platforms are as-expected and my NFS share on Linux works perfectly. But on Windows, my Samba shares seem to randomly have some huge "connection" latency. Most of the time, they work more or less as expected. But every so often, simply doing the initial access of the shares (for example, browsing to open a file that lives on a share), takes a good minute or more. But once I get past that initial delay, the actual throughput is near line rate. When things get frustratingly bad, I find that stopping and restarting the Samba service (on the TrueNAS system) usually helps (although, the most recent time this happened, my Windows mapped drives were so "stuck" that I gave up and additionally rebooted Windows).

I did briefly try giving up NFS for Linux, and using Samba across the board instead... This worked, but my permissions in Linux weren't right. I don't remember exactly what wasn't right, as this was a while ago. But also the performance was worse - not in terms of bulk throughput, but e.g. simply doing an "ls" on my home directory had that tiny-but-perceptable lag (whereas it always felt instantaneous with NFS). I didn't run that way very long, because I didn't feel like spending the time and effort to further configure and tune it.

Good luck, let us know if you meet with any success!

 

[PhilD13]

as @ABain suggested, Use multiprotocol shares.

 

[RandomPrecision]

In Cobia you do have the option to add multiprotocol shares: https://www.truenas.com/docs/scale/23.10/scaletutorials/shares/mixedmodeshares/

as @ABain suggested, Use multiprotocol shares.

I'm curious to hear about people actually using this. Anyone else out there with a dataset that is shared out by both Samba and NFS, particularly a home directory shared between Linux (NFS) and Windows (Samba)?

I looked into this when I saw it as part of the Cobia release notes: Cobia SMB and NFSv4 Compatibility Profile. As I mentioned in that thread, the documentation only covers creating new shares, doesn't speak to exactly what happens behind the scenes with the new presets (so that it can be replicated for existing shares). And as @anodos said (emphasis mine):

This is just a preset some of settings are create-time only (like forcing case-sensitive). It sets NFSv4 acltype with PASSTHROUGH aclmode, and a default ACL.

Doing these things will address some, but not all issues users may have when doing concurrent multiprotocol access. Onus, as always, is on the system administrator to understand details of protocols and applications accessing data and make appropriate design decisions for network storage.

I did spend some time trying to get things to work correctly and consistently, though admittedly pre-Cobia. I might have better luck if I were to recreate the shares from scratch using the new multiprotocol support. But as noted above, even that may not address all issues. There are a lot of unanswered questions on this forum dealing with ACLs and share permissions.

 

[anodos]

I did spend some time trying to get things to work correctly and consistently, though admittedly pre-Cobia. I might have better luck if I were to recreate the shares from scratch using the new multiprotocol support. But as noted above, even that may not address all issues. There are a lot of unanswered questions on this forum dealing with ACLs and share permissions.

NFSv4 ACL type has ability to specify whether an entry inherits on files or directories (or both). If you have specific need to not inherit execute on files you can create pairs of explicit ACL entries (one for files (that lacks execute) and one for directories).

As far as unanswered questions go, the forums are a community effort and so not every question gets answered (there is no software support entitlement for free users). For example, I am not a forums admin and I answer questions as I have time to help the community, and sometimes -after seeing same questions that are covered in our documentation and existing threads - I opt not to respond.

But on Windows, my Samba shares seem to randomly have some huge "connection" latency. Most of the time, they work more or less as expected. But every so often, simply doing the initial access of the shares (for example, browsing to open a file that lives on a share), takes a good minute or more. But once I get past that initial delay, the actual throughput is near line rate. When things get frustratingly bad, I find that stopping and restarting the Samba service (on the TrueNAS system) usually helps (although, the most recent time this happened, my Windows mapped drives were so "stuck" that I gave up and additionally rebooted Windows).

You can check whether this is brought on by kernel oplock coordination switching off the SMB share preset. Another variant with slow directory loading is where dirs with very large numbers of files may load slowly before file metadata is cached.

 

[PhilD13]

I'm using the multiprotocol on one servers datasets along with SMB and windows 10/11 and Linux comuters all see and can access create/delete etc. files and directories without issues. On another server I use SMB as the dataset protocol option on the dataset along with SMB and have no issues with use on windows10/11, Linux. On my Test Virtualbox Truenas, I use the default General option and SMB. On each server the permissions/ACL setup is slightly different but the end result is the same everyone has access to the shares I want them to use. You will need to figure out the ACL/permissions you need for your use case. If you think they are messed up, you can always strip them and start fresh.

I don't have users home directories mapped in SMB (only certain directories we need to use are mapped to SMB etc.) so I can't say for sure if the following is correct. I think by default home directories are connected to the particular users account only and when the user logs in can they access the directory properly and to be available to others on top of what other permissions and mapping is needed you would also need to adkust ACL of the home directory in the user setup. Home shares should I think be created on a normal dataset set to general.

 

[RandomPrecision]

As far as unanswered questions go, the forums are a community effort and so not every question gets answered (there is no software support entitlement for free users). For example, I am not a forums admin and I answer questions as I have time to help the community, and sometimes -after seeing same questions that are covered in our documentation and existing threads - I opt not to respond.

Apologies if my replied-to comment came across as snarky, that wasn't my intent. I understand it's community supported (if I'm not paying), and all the caveats that come with that. (I was going to say, it's a "you get what you pay for" thing, but that's really not fair to TrueNAS, as I haven't paid anything but I'm getting a really nice piece of software!) My point was that, going by the number of questions on the topic that are unanswered, it seems to be a common struggling point for a lot of people. Many of these questions are the same questions I have, but I haven't been able to find answers to them in the documentation.

You can check whether this is brought on by kernel oplock coordination switching off the SMB share preset. Another variant with slow directory loading is where dirs with very large numbers of files may load slowly before file metadata is cached.

Thanks, I'll look into the former suggestion. It's definitely not the latter, because I get this onerous delay on the "inital" listing of a Samba-shared mapped drive (in Windows), even when that share has a very small number of files. It feels very much like something is stuck and forced to timeout before it can continue.

I'm using the multiprotocol on one servers datasets along with SMB and windows 10/11 and Linux comuters all see and can access create/delete etc. files and directories without issues. On another server I use SMB as the dataset protocol option on the dataset along with SMB and have no issues with use on windows10/11, Linux.
(...)

Just to be clear, you have the same dataset(s) that are shared out via both Samba and NFS?

 

[PhilD13]

Just to be clear, you have the same dataset(s) that are shared out via both Samba and NFS?

The datasets are shared by SMB and the datasets were setup slightly differently as described on each system. Not on purpose, but I was in a hurry and am not the best at the permissions and each system used a different version (Bluefin, Cobia, Dragonfish) of Truenas. I did not need to set up anything special for Linux to access the shares as once setup for the windows computers they are also accessible from Linux (PopOS!) laptop. I basically folowed the Scale documentation on how to setup the datasets and shares.