Newbie struggling to get permissions and ACL configured

[James]

Hi there! I have installed the latest version and created a RAIDz2 pool with a couple of datasets. I have spent several hours going through the documentation and YT videos to learn how to set the permissions and accounts (groups and users) for datasets and shares - yet, I am here without any success. I am hoping someone can help on this topic or point me to a link, and I will give a try again.

Steps that I followed:
1. Storage: Create a pool (storage) >> create a generic dataset (music)
2. Accounts: Create a new group (john) with samba authentication
3. Accounts: Create a new user (james) >> tag it to newly created group (john) >> nonexistent directory >> user all access, group only read access and no access to other
4. Sharing: Add music >> create custom ACL >> on the left-side panel, changed user and group to james and john (applied settings) >> on the right-side panel, owner@ with full control and group@ with read control. Deleted everyone@.
5. Services - SMB stop and start
6. Windows - map network drive >> \\IPaddress/mnt/storage/music >> credentials "james" and "pswd" .... Windows keep prompting for password or sometimes the network password is incorrect
7. getfacl on the music folder confirms james as the owner with full access and john group with read access as defined. The owner of the /mnt/storage is root and wheel.

I would like to create a few datasets and add files from the Windows after mapping. I don't know what I am missing and would appreciate some advice to configure my SMB share.

Best,
James

 

[AndroGen]

Hi James,
when you create any object (data set, user, SMB share and etc.) - you need (here - it might be not the "official statement") to create them with SMB enabled during the creation.
I would not say: this is the must, but this is my experience. Enabling SMB "later" did not work for me.
I has all sort of funky issues, mostly related to the authentication.
Andrey

 

[James]

Hi James,
when you create any object (data set, user, SMB share and etc.) - you need (here - it might be not the "official statement") to create them with SMB enabled during the creation.
I would not say: this is the must, but this is my experience. Enabling SMB "later" did not work for me.
I has all sort of funky issues, mostly related to the authentication.
Andrey

Thank you, AndroGen, for the suggestion. I may have tried that approach too but also updated ACL before sharing. So, are you just enabling SMB while creating a dataset and not doing anything further after that (from Sharing menu >> ACL configurations)? Where did you set the owner/group - through dataset permissions?

 

[winnielinnie]

6. Windows - map network drive >> \\IPaddress/mnt/storage/music >> credentials "james" and "pswd" .... Windows keep prompting for password or sometimes the network password is incorrect

Windows uses backslashes instead of forwards slashes (not sure if maybe you wrote that in here differently).

Besides that, you don't use the entire path as it is on your TrueNAS server itself, but rather you should use your Share Name as the root directory when connecting to the network share (assuming your SMB Share Name is "music"):

\\ip.address\music


Does trying it this way make any difference?

 

[AndroGen]

So, are you just enabling SMB while creating a dataset and not doing anything further after that (from Sharing menu >> ACL configurations)?
Where did you set the owner/group - through dataset permissions?

Sure, I have created few groups, added users to these groups, then edited all ACL per Data sets and per share, that I could achieve needed results.
In my case I've chosen to have 2 levels dataset structure, where the high level is for share, and next level was to restrict the permissions as it was needed.

Then I've shared the higher level Data Set, and all can see / use only those 2nd level datasets where they have access to. Some second level data sets had full permission for all, some read only.
and there have been multiple 1st level datasets, one per specific purpose, and the main "differentiation" of access rights was on the 2nd level.
on 2st level no one can create anything - this allows the control of what can be created (apparently nothing) within 1st level dataset.
Main reasons why I've gone this way:
- it is possible to have individual snapshots per 2nd level dataset
- it is possible to have independent quotes per 2nd level dataset

in your story it would be:
share: "music" - this is also 1st level dataset in my setup, and then multiple different "libraries" (2nd level datasets) within the share "music"
e.g.
\\xxx.xxx.xxx.xxx\music\jazz
\\xxx.xxx.xxx.xxx\music\interviews
\\xxx.xxx.xxx.xxx\music\userX <- e.g. if this use has "personal collection of something
and in my setup:
"music" - is SMB share
"music" - is 1st level dataset, which is used for share "music"
"jazz" - 2nd level dataset within "music" dataset
"interviews" - 2nd level dataset within "music" dataset
"userX" - 2nd level dataset within "music" dataset
each dataset has own ACL permissions according to defined access rights

in case of e.g. another topics, e.g. video - it would be separated 1st level dataset with dedicated second level structure.
but, again, this is my approach. and I do not know whether it is a "best practice"

I hope, it helps,
Andrey

 

[ChrisRJ]

Hi James,
when you create any object (data set, user, SMB share and etc.) - you need (here - it might be not the "official statement") to create them with SMB enabled during the creation.

Is this new for TrueNAS? I am still running FreeNAS but was not aware of this. But I agree that the SMB sharing user experience has room for improvement. At least for me not using ACLs but traditional user/group settings was always better.

 

[AndroGen]

Is this new for TrueNAS? I am still running FreeNAS but was not aware of this. But I agree that the SMB sharing user experience has room for improvement. At least for me not using ACLs but traditional user/group settings was always better.

This is my experience with fresh TrueNAS install. I cannot say whether this is a "must", or my solution for the problems I had initially, or workaround - I cannot say. I was a bit tired to trace the real root cause for my authentication issues. The tracing issues was too time consuming for me.
Recreating all with SMB "ON" during the creation has solved my issues - hence, I just share my experience.

 

[Constantin]

I found it went both ways with a Mac. That is, the best way to approach permissions issues was to detach all shared volumes, turn off SMB, adjust sharing settings, and then re-enable SMB before connecting back. Deleting the /etc/nsmb.conf file on the Mac was also necessary. Some settings still need help, i.e. I went down to the command line to manually adjust directory / content ownership using the CLI.

I still haven't figured out PhotoSync. Worked on the old pool with SMB under 11.3 without ACL permissions but still doesn't work in TrueNAS. Everything else works but still think I could use a good course on how to set up ACLs properly. Presently, I may have some areas open that shouldn't be.

 

[Patrick M. Hausen]

I just disable ACLs completely and use Unix permissions as god intended
This still works and I have not seen a deprecation notice, yet.

 

[Constantin]

Not deprecated, true.

But to any user of the TrueNAS UI, whenever you try to adjust file permission settings of a SMB share, the ACL menu is presented by default even if the admin explicitly asked the share to have ACLs stripped off.

The bias of the TrueNAS UI designer towards the use of ACLs is a strong one. I consider this bias to be a bug, not a feature. On the other hand, using ACLs likely makes sense re: windows and Mac integration.

so I have to learn some more. Perhaps one day PhotoSync will work again.

 

[James]

Sure, I have created few groups, added users to these groups, then edited all ACL per Data sets and per share, that I could achieve needed results.
In my case I've chosen to have 2 levels dataset structure, where the high level is for share, and next level was to restrict the permissions as it was needed.

Then I've shared the higher level Data Set, and all can see / use only those 2nd level datasets where they have access to. Some second level data sets had full permission for all, some read only.
and there have been multiple 1st level datasets, one per specific purpose, and the main "differentiation" of access rights was on the 2nd level.
on 2st level no one can create anything - this allows the control of what can be created (apparently nothing) within 1st level dataset.
Main reasons why I've gone this way:
- it is possible to have individual snapshots per 2nd level dataset
- it is possible to have independent quotes per 2nd level dataset

in your story it would be:
share: "music" - this is also 1st level dataset in my setup, and then multiple different "libraries" (2nd level datasets) within the share "music"
e.g.
\\xxx.xxx.xxx.xxx\music\jazz
\\xxx.xxx.xxx.xxx\music\interviews
\\xxx.xxx.xxx.xxx\music\userX <- e.g. if this use has "personal collection of something
and in my setup:
"music" - is SMB share
"music" - is 1st level dataset, which is used for share "music"
"jazz" - 2nd level dataset within "music" dataset
"interviews" - 2nd level dataset within "music" dataset
"userX" - 2nd level dataset within "music" dataset
each dataset has own ACL permissions according to defined access rights

in case of e.g. another topics, e.g. video - it would be separated 1st level dataset with dedicated second level structure.
but, again, this is my approach. and I do not know whether it is a "best practice"

I hope, it helps,
Andrey

AndroGen, thank you so much for taking time to help with detailed steps. I really appreciate it. I understood for the most part and will give a try today. However, what is still confusing is that while creating a new user, there is an option at the bottom to set directory permissions for "group" and "other" - so, let's say an user "ABC" is tagged to primary group "XYZ" - is this the place where permissions for the group "XYZ" is set?

If I add another user, and tag it to "XYZ," the bottom part of the group permissions still points to default permission - it doesn't reflect what was defined earlier. This is the case with other built-in groups too. Changing primary group, doesn't do anything at the bottom. I can't even think of what "other" means - can any user read the file if other is set to read? if so, why do we have a user and password?

The document states unix like permissions, and I read user and group permissions, which I thought was logical. However, I cannot transform that learning here given multiple layers of permissions.

 

[James]

Windows uses backslashes instead of forwards slashes (not sure if maybe you wrote that in here differently).

Besides that, you don't use the entire path as it is on your TrueNAS server itself, but rather you should use your Share Name as the root directory when connecting to the network share (assuming your SMB Share Name is "music"):

\\ip.address\music


Does trying it this way make any difference?

Thanks winnielinnie! This is such a cool tip that I wasn't aware of. Appreciate it. I will try as suggested.

 

[James]

AndroGen, thank you so much for taking time to help with detailed steps. I really appreciate it. I understood for the most part and will give a try today. However, what is still confusing is that while creating a new user, there is an option at the bottom to set directory permissions for "group" and "other" - so, let's say an user "ABC" is tagged to primary group "XYZ" - is this the place where permissions for the group "XYZ" is set?

If I add another user, and tag it to "XYZ," the bottom part of the group permissions still points to default permission - it doesn't reflect what was defined earlier. This is the case with other built-in groups too. Changing primary group, doesn't do anything at the bottom. I can't even think of what "other" means - can any user read the file if other is set to read? if so, why do we have a user and password?

The document states unix like permissions, and I read user and group permissions, which I thought was logical. However, I cannot transform that learning here given multiple layers of permissions.

Hi - I thought it would be easier if I attach an image. Please see the screenshot below

 

[James]

I just disable ACLs completely and use Unix permissions as god intended
This still works and I have not seen a deprecation notice, yet.

Hi Patrick, can you please elaborate on that? Would that work for Windows share as well?

 

[winnielinnie]

Hi - I thought it would be easier if I attach an image. Please see the screenshot below

That's because your user does not have a real home directory.

3. Accounts: Create a new user (james) >> tag it to newly created group (john) >> nonexistent directory >> user all access, group only read access and no access to other

You set their "home" to /nonexistent

 

[AndroGen]

Hi - I thought it would be easier if I attach an image. Please see the screenshot below

Your image shows the Unix like permissions, and not the ACL.
You need to switch to ACL - then you would get much more possibilities, and you could have multiple users and groups assigned to the same object with different set of permissions
As a suggestion: have a look these two video.
It is an old FreeNAS version, but it has very good explanation of steps and what needs to be done.

- YouTube

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

youtu.be

- YouTube

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

youtu.be

Then you might watch e.g. Lawrence's video about SMB / ACL topic with much new version - this would give you a good foundation for your next steps.

TrueNAS Core 12 User and Group ACL Permissions and SMB Sharing

Connecting With Us--------------------------------------------------- + Hire Us For A Project: https://lawrencesystems.com/hire-us/+ Tom Twitter https://...

youtu.be

 

[James]

Your image shows the Unix like permissions, and not the ACL.
You need to switch to ACL - then you would get much more possibilities, and you could have multiple users and groups assigned to the same object with different set of permissions
As a suggestion: have a look these two video.
It is an old FreeNAS version, but it has very good explanation of steps and what needs to be done.

- YouTube

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

youtu.be

- YouTube

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

youtu.be

Then you might watch e.g. Lawrence's video about SMB / ACL topic with much new version - this would give you a good foundation for your next steps.

TrueNAS Core 12 User and Group ACL Permissions and SMB Sharing

Connecting With Us--------------------------------------------------- + Hire Us For A Project: https://lawrencesystems.com/hire-us/+ Tom Twitter https://...

youtu.be

Thank you, AndroGen, for sharing very helpful links. I managed to get through the credentials error by enabling SMB share directly in the dataset. I appreciate your support.

 

[James]

That's because your user does not have a real home directory.



You set their "home" to /nonexistent

Thanks, winnielinnie. You are right, I didn't see that happen after selecting the directory. Appreciate your comments.

 

[James]

I just disable ACLs completely and use Unix permissions as god intended
This still works and I have not seen a deprecation notice, yet.

Hi Patrick, I tried this approach - stripped ACLs and applied unix like permissions. Much easier to follow and what I was hoping for my set up. Thanks!

 

[AndroGen]

Just reading some other posts I have seen multiple discussion about nested datasets and some associated to it issues.
hence, please explore this topic. My approach (nested datasets), indeed, might be not the best one.