Hi All,
I have been trying to read and understand some of the articles I saw online regarding SMB sharing but not much resources related to AD. I configured a SMB share and the default permission is everyone with full control. I look at the file system ACL and there are some groups + users there by default (owner, domain admins etc…).
I can’t remove domain users from the share or else the users can’t connect to the share and drop files in.
Does it work like Windows does where everyone gets full control and from there you restrict based on the folder permission? I added a group but if I connect with a user that shouldn’t have permissions I can see everything and make changes if necessary.
What am i doing wrong here?
Yes. That’s how it works. Generally you assign full control to everyone in the ACL, then modify the filesystem ACL to restrict access.
A few possible reasons for this:
- SMB token is generated on first connection to server. If you were editing groups afterwards then server won’t see the changes
- It’s possible that the user or its primary group owns the directory where you’re creating files / reading data. Owner rights trump everything else (like in Windows)
Yea I just tried again with a different account and it seems to have worked out correctly.
I created a second data set that I wanted shared via SMB, permission structure managed with AD. This time around when I edit the file system, I am asked to choose an ACL profile which never happened the first time. Is this normal?
I took a look at my original SMB share and the permissions are vastly different
The second one share I created isn’t carrying anything similar with the permissions listed.
Feels limited in a sense and before the permissions populated automatically with the windows groups etc…
Am I doing something wrong?
Latter case is using POSIX ACL type. You typically want NFSV4-style.
Generally best way to create an SMB share is to create the dataset with the SMB preset.
Weird, it is an SMB share but I don’t know how the NFSv4 permission style applied. I look at the settings of the share and its set to default.
So if the SMB share is set with the SMB ACL, can I then just go and use windows explorer to manage the permissions granting users access on the shares?
Before you replied I was looking at this article:
I managed to figure it out. It seems my original share was configured under NFSv4 even though it was an SMB share. Permissions seems to apply better with AD groups and users compared to SMB (skill issue on my part).
For those who read this later, I went into the details of the dataset tile and under advanced, there is an option for changing from Posix to NFSv4/SMB, making the ACL restricted.
I hope my settings don’t affect apps such as Minio but I will be testing that before making this available to everyone. I’ll post updates.
@awalkerix thanks for your guidance.
I just realized that the initial dataset is set to a posix permission structure, @awalkerix will this affect overall operation for the rest of the shares within it?
Ex.
Dataset storage - Posix
- folder1 - NFS
- folder2 - NFS
As long as you’re not directly sharing the “data storage” dataset, it’s fine. Mixing and matching acl types within a share path is unsupported and will generate an alert.
Thanks @awalkerix so it would be best to just redo the whole dataset and make it all the same permission structure to avoid issues down the road? I still have nothing on this dataset anyways so starting over isn’t an issue.
Generally it’s best to do one dataset per share and not nest them.
dataset: tank/share1 -> share [share1]
dataset: tank/share2 -> share [share2]
...
Is there any reason to why each dataset should be its own folder that is shared rather than nested like traditional storage solutions?
A dataset isn’t a directory. If you need directories, create those within the dataset and share them. Some SMB clients do not handle nested datasets well. For example MacOS clients will fail to rename files across dataset boundaries.
e.g.
dataset: tank/SMB
|
--> directory: /mnt/tank/SMB/directory1 -> share [share1]
|
--> directory: /mnt/tank/SMB/directory2 -> share [share2]
Though I don’t see any real advantage to doing this as opposed to using separate datasets for the shares.
1 Like
Nesting datasets within an SMB share is more akin to creating multiple NTFS volumes and mounting them inside an existing NTFS volume inside an SMB share, which is a design that can backfire spectacularly if the developer for some $randomsmbclient doesn’t realize it’s possible.
Apologies but I am a visual poerson, currently mine looks like this:
“storage” is main one that has the posix acl
To create those additional “folders” like content and footage i have been using the “create dataset” because I didn’t see any other option to a simple directory which should be shared.
I was using this as my source of understanding:
Adding and Managing Datasets | TrueNAS Documentation Hub.
Right. So don’t explicitly share storage. Just share the datasets you created content and footage.
Gotcha, i was on the right track with my image then.
Now the other topic I would like to clarify is the storage pool and its permission structure. When I view the details of that dataset/pool in the same page as the image above it shows the ACL is posix. From my understanding, mixing ACL isn’t recommended.
Should I delete my pool and recreate it or leave it be?
Btw, @awalkerix thank you for your patience and answering all my questions.
The situation to avoid is something like this:
- dozer/SHARE - POSIX
- dozer/SHARE/photos - NFSV4
and sharing out dozer/SHARE.
Having
- dozer - POSIX
- dozer/SHARE - NFSV4
And sharing dozer/SHARE is fine (everything within share path has same ACL type).
1 Like
That is far more clear now, thanks for your assistance.
Btw is this a normal output for MacOS (doesn’t do this on windows):
You’re probably using apple SMB extensions and we’re not advertising that capability.
