Change umask for user with /nonexistent home folder

TrueNAS General
,
1

afternoon folks, using a truenas core 13 system and have created a couple of users. When I created the users I took the default of /nonexistent home folder - so now that these two users are used in a group - I think I need to change their umask from 0022 & 22 so that when they create files that do not keep the group with no write access. Is there a place to change their umask? or should I recreate the users and give them a /home/folder so it can be modified? Or is there some way of modifying the umask with the web interface of TrueNas Core for the user?

Thanks for any assistance.

2

What are you referring to here?

No need to recreate a user to give them a home folder (assuming the path exists.)

The only thing you would be modifying is the home folder’s Unix permissions.

3

sorry I was so vague before - I have this folder

file: controller

owner: kevin

group: controller

        owner@:rwxpDdaARWcCos:fd-----:allow
        group@:rwxpDdaARWcCos:fd-----:allow
        everyone@:--------------:fd-----:allow

There are only two users that I want to be able to use this folder, the owner kevin and another josie. Already kevin as the owner and working fine (or so I thought) with the folder - so I added another user josie and made her a member of group controller. Thinking that both users should be able to create and edit files in this datastore because they are both memebers of the group. But every file each of them creates have the file permissions:

-rw-r–r–+ 1 josie controller 8623 Sep 27 14:30 Josie test spreadsheet.xlsx
-rw-r–r–+ 1 kevin controller 8586 Sep 27 13:49 Kevin test spreadsheet.xlsx

the created files do not adjust the permissions to allow write access for the group - I expected -rw-rw-r–+ for any file either of them created in this location. So I started Googling for possible reasons, and the Internet pointed me to the umask - not sure if thats the culprit or not, but that is where Google and ChatGPT took me. So when I started looking into changing the umask, everything refers to modifying files in the /home folder of each user, however when I created the users - I did not give them a home folder it is set to /nonexsistent (the default for TrueNas core). Which lead me to asking the question about chaning the umask.

While re-writing this question with more detailed information I found in the TrueNas web interface under Accounts>Users that I can edit the user and change their home directory permissions - is that essentially modifying the users umask? Or should I modify something else entirely - just not sure of the propper way in truenas core to make it so that users belonging to the same group can create files in the group location that are editiable by all memebers of the group.

4

And thanks for your reply! hope you have a great weekend!

5

umask is strictly for traditional Unix permissions which are largely irrelevant if the users work with the files/folders via SMB shares. You need to look into the ACLs instead. That’s in the UI.

1 Like
6

Also, isn’t umask something handled by the client / software? Nothing about changing a directory’s permissions has any bearing on how the client / software tries to set the permissions on newly written files, correct?

So there’s nothing in the TrueNAS GUI that would affect the umask of whatever session is being used. (Especially for a Windows client over SMB.)

I might be fuzzy on this one.

7

@David_Anderson

  1. I created a new dataset and set its “Share Type” to “SMB”
  2. Made my user the “owner” and “builtin_users” the “group owner”
  3. Set an ACL preset to “Home”, then changed @everyone to “Basic/Traverse”
  4. Created an SMB Share that points to this dataset, with the default preset

Here’s what I observed:

Creating new files directly on the server (via an SSH session) works as expected. The new files yield these permissions:

# file: newfile.txt
# owner: winnie
# group: builtin_users
            owner@:rwxpDdaARWcCos:------I:allow
            group@:rwxpDdaARWcCos:------I:allow
         everyone@:--x---a-R-c---:------I:allow
         everyone@:--------------:------I:allow

-rwxrwx--x+

Copying a file to the SMB Share from a Windows 10 client via File Explorer also yields the same results.

Is this what you expected?

I’m on TrueNAS Core 13.3-RELEASE.

8

Umask is the bits which are forcibly cleared by the OS in addition to whatever the user process might ask for.

So if the umask is 022 and the user process asks for 666, the effective bits will be 644. Of course the user process is free to create a file 600 if it so desires but it cannot set e.g. 660 with an umask setting of 022.

So the OP was on the right track for interactive shell use. Most programs don’t ask for anything special so 666 & umask is what gets set as a result. Changing the umask from 022 to 002 would have enabled that group writeable bit.

But only for interactive shell use or other programs (cron jobs) executed as that particular user directly on the system.

Now in the case of a Samba share that user process is smbd. The umask setting is in this case set in the share configuration:

https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#CREATEMASK

1 Like
9

But is that “technically” a umask? Its own tooltip reads that the default value is 0666, so that written files are read-write for everyone by default.

Likewise, 0777 for directories.

EDIT: Are those two settings (“file creation mask” and “directory creation mask”) essentially ignored if you are using ACLs?

10

To my knowledge, yes. @awalkerix can you confirm?

11

Both of these users are accessing the truenas share via Windows clients - just file manager and excel I believe (for the majority) - and when they open the share - they must log in with the account that was created on TrueNas before they can access the share. (We are not complicating things with AD or anything like that) - we have even eliminated the domains in windows.

I was just figuring there should be a way in the Web interface to make this change - just adding a user to a group (that has full access to the share) does not do it. So if there is a specific way in TrueNas Core to make this happen, that’s what I was asking for - intuitively - I would think a valid user on the system added to the group controller would have read write access to files in that folder.

12

You need to edit the dataset ACL to allow group writes and set some “inherit” property or some such, if I remember correctly.

USE ACL Manager Screen

13

Thanks guys, you’ve given me place to dig into at least! Hope you all have a great rest of your weekend!

14

It depends on what the ZFS aclmode is set to.

  • RESTRICTED - attempts to chmod will fail with EPERM if ACL is defined
  • PASSTHROUGH - ZFS ACL will be modified to match the expected mode with often unintended consequences and user confusion because the application doing this is not ACL-aware and tends to be very ham-fisted.

Owner@, Group@, Everyone@ approximately match up with conventional UGO. If those are the only entries defined in your ACL and you have configured PASSTHROUGH aclmode, then you will most likely be in for a rough time as your intended permissions not last through a round of $random_application having its way with your data.

If you want to let the application have its own way with permissions (because it’s poorly designed in this area and errors out if chmod fails - for example immich does this IIRC), but still keep the level of access assurance for particular groups. Then you can leave the special ACEs (owner@, group@, everyone@) with NOINHERIT set, define explicit access for one or more groups, and set the ZFS aclmode to PASSTHROUGH.

If the OP was only accessing through SMB and concerned about inherited permissions, then they should set ACLs and make sure the ZFS aclmode is set to RESTRICTED (which is our default).

1 Like
15

I would guess its set to default, as you guys are all talking about things I have never messed with. Looking like I will be doing some experimentation this week to see if I can get it to act as I think it should. Thanks again for all the information and suggestions.

16

I did get a chance to do some experimenting this morning, and can confirm that is it doing the following:

Using the web interface and connecting to >_ Shell
if I su username and touch a file inside this shared folder controller - I get the following:

root@truenas[…Pool/datastore/storage/controller]# su josie
$ touch testfile2.txt
$ ls -la testfile2.txt
-rwxrwx—+ 1 josie controller 0 Sep 30 10:22 testfile2.txt
$

So I see the + and rwx for both owner and group in permissions indicating that it must be using ACL permissions for this type of access (shell) I think.

If I use windows explorer from a windows 10 computer (connecting to the share via \ipaddress\controller) and getting prompted to login, I logged in as the same user, I get:

$ ls -la testfile2smb.txt
-rw-r–r-- 1 josie controller 0 Sep 30 10:23 testfile2smb.txt
$

No + and rw- for owner josie r-- for group and r-- for other - so not using ACL for SMB - again I think.

Checking the web interface Storage\Pools\Edit Dataset (for controller) I do see that the ACL mode is set to Passthrough

Still not sure of the cleanest - proper way to resolve this issue:

  1. Modify the users involved and give them a Home folder so I can set a umask for each? If so, can that be done with the web interface? or should I get into the shell and follow some FreeBSD guidance on user management to add a home folder for each and then set a umask file to 002.

  2. Modify the share ACL via the web Interface Sharing / Windows Share SMB / Edit Share ACL OR Edit File Server ACL or Both - not really sure what am I supposed to change in there to make it work as expected when its already got

file: controller
owner: kevin
group: controller
owner@:rwxpDdaARWcCos:fd-----:allow
group@:rwxpDdaARWcCos:fd-----:allow
everyone@:--------------:fd-----:allow

for Group and Owner

  1. Create a new dataset / share - I could follow the steps given by winnielinnie
    TrueNAS MVP above and then move the data, and then recreate the connections for each desktop needing access to the new share.

  2. something completely different that I have not come across as of yet

I totally see that I am starting to sound like a "you make my ship go " kinda dork - and I really thought I had researched and found the direction I needed to go with the umask solution, it could quite possibly be that I am using a tank to swat at fly and I should move to a simpler NAS solution as well when these iXSystems boxes start to falter - I did not foresee this use case when I removed the windows file server and AD domain as we had not done anything like this in the past 10 years. I really must be missing something as it seems to me that this should be simpler than its turning out to be.

Any suggestions of the correct approach to take are much appreciated.

I think I can also deduce that this share was originally created as a Generic share rather than an SMB share - (I am basing this on rebuilding the setup I have going on a test mini NAS server and I can see my case sensativity is sensative rather than insensative as it would be if I had chosen SMB - even if it cannot be changed, be nice if the original share type was greyed out).

17

It looks like you’re presenting us with an XY problem that’s getting fed by unhelpful chatgpt output.

I take it you’re trying to create an SMB share that two users can write to.

  1. Create dataset with “SMB” acltype preset (at the top level of pool - not deeply nested).
  2. Set an ACL that with an explicit GROUP (not GROUP@) entry for a group that the two users share in common

Those are the only two steps that are required (unless you’ve followed some obscenely bad online advice to change permissions on /mnt/pool from shell).

2 Likes
18

Odd that you would say that (about ChatGPT)! Actually I am not trying to create a new share, I’m trying to avoid having to create a new share and use the existing one. Where I think the real problem is coming into play, is that this share was originally created way back in freeNAS something or other quite a few years ago. Now that we are on TrueNAS core 13 some older default settings are causing issues with a means to address this - maybe - I am totally guessing but that seems like it to me.

Was funny you said bad info from ChatGPT as I would say the reverse was happening - if you ask the question specifically (specificity really counts here) and directly it can actually be more helpful than anything. For example, asking how to change the home folder in FreeBSD - try that on the internet and in general ya get nothing useful - only how to create new - ChatGPT gives you correct steps (useless for TrueNAS Core though, as it seems to require the home folder for users be in /mnt for some reason) and was pretty easy to follow. I get the feeling I am just going to have to create a new share as you suggested - would it be a bad idea to create a new dataset called controller2024 following your steps, but share it with the same SMB name of controller$? or should I just deal with a complete rebuild with all new names to avoid any conflict? once it is set up and creating files as expected, I will use the owner of the share to move all the files over and reset the permissions.

(I added to my ChatGPT question about modifying the users home folder “would this work for TrueNAS core 13”, and it actually correctly updated to add using the dataset for home directories - just like any tool can be useful or could cut off your thumb!)

19

I created a new dataset on a test mini - for this dataset, I chose SMB type rather than generic, and used ACL to create a restricted share. (I was unsure about your step 2 above) when I made the dataset, I made kevin the owner and manager the group recursively for the entire thing). Seems to be working just as expected - I think my problem stems from a dataset that was created pre ACL on a system that is now ACL based. I’ll do a bit more testing and should be able to create the new dataset on the production server and experiment with the share before approaching the users. Sorry for the round about approach to getting to a resolution, but I was trying to avoid moving the data around for some stupid reason (FUD i’d expect & not feeling confident enough in all the buttons and settings most likely).

20

Thanks to all of you who helped with this - creating a new share is working out just as expected.