Permissions not persisting

[M H]

I was holding off on upgrading to 9.3 for quite some time because everything was working great. I was on 9.2.1.8.

I noticed that there was some replication improvements in 9.3 so I decided to go ahead and it has been a total nightmare with permissions. Previously, I used all unix permissions (even with CIFS) and everything worked fine. Now, I'm assuming because of a CIFS upgrade, my unix permissions no longer work. Ok, no big deal, change the permissions to Windows and set them in Windows Explorer right?

No go, none of my permissions persist exposing sensitive information to the entire network. It keeps adding "Everyone" to every share even though I have removed it several times. It's almost like my permissions are getting reset somehow. I'm signed into Windows Explorer with the root account so that it has access to make permission changes.

I'll make a permission change, it will look like it was accepted and shows correctly in the "Security" tab, but then some time later, maybe an hour +, the "Everyone" user returns exposing all of my shares to everyone again. Please help, I'm about to go back to 9.2.1.8, because I simply cannot trust FREENAS not to expose sensitive information.

 

[anodos]

I was holding off on upgrading to 9.3 for quite some time because everything was working great. I was on 9.2.1.8.

I noticed that there was some replication improvements in 9.3 so I decided to go ahead and it has been a total nightmare with permissions. Previously, I used all unix permissions (even with CIFS) and everything worked fine. Now, I'm assuming because of a CIFS upgrade, my unix permissions no longer work. Ok, no big deal, change the permissions to Windows and set them in Windows Explorer right?

No go, none of my permissions persist exposing sensitive information to the entire network. It keeps adding "Everyone" to every share even though I have removed it several times. It's almost like my permissions are getting reset somehow. I'm signed into Windows Explorer with the root account so that it has access to make permission changes.

I'll make a permission change, it will look like it was accepted and shows correctly in the "Security" tab, but then some time later, maybe an hour +, the "Everyone" user returns exposing all of my shares to everyone again. Please help, I'm about to go back to 9.2.1.8, because I simply cannot trust FREENAS not to expose sensitive information.

Okay. While you are debugging the permissions problem, you can define a list of users with access to the share by using the "valid users" parameter. Add as an auxiliary parameter

Code:

valid users = @group

See complete syntax here: https://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#VALIDUSERS

This will prevent exposing data through the everyone ACE.

 

[M H]

Thank you. This helps, but I only have 1 share, with permissions controlling everything inside. Any other suggestions? Should I really start separating out my shares?

 

[anodos]

Thank you. This helps, but I only have 1 share, with permissions controlling everything inside. Any other suggestions? Should I really start separating out my shares?

Using the CLI, check the aclmode for the dataset you're sharing

Code:

zfs get aclmode <pool>/<dataset>

. It should be "restricted". If it is, run the following command through the CLI

Code:

winacl -O root -G wheel -a reset -r -p /mnt/<pool>/<dataset>

Once you do this, set permissions through windows explorer using your root credentials.

 

[M H]

Thank you! aclmode is set to "pass-through." I have been setting the permissions with my root account in Windows. Yesterday, all of my permissions were correct for the most part. Today, every single folder as "Everyone" added again.

 

[anodos]

Thank you! aclmode is set to "pass-through." I have been setting the permissions with my root account in Windows. Yesterday, all of my permissions were correct for the most part. Today, every single folder as "Everyone" added again.

Okay, you can fix the aclmode by typing

Code:

zfs set aclmode=restricted <pool>/<dataset>

This is a fairly common problem when the aclmode is set incorrectly.

 

[M H]

Can I set this on the entire pool? Or must I do it on datasets?

 

[M H]

Ok, the pool now shows as "restricted." Is that it? Should it be all rainbows and unicorns now?

 

[M H]

Using the CLI, check the aclmode for the dataset you're sharing

Code:

zfs get aclmode <pool>/<dataset>

. It should be "restricted". If it is, run the following command through the CLI

Code:

winacl -O root -G wheel -a reset -r -p /mnt/<pool>/<dataset>

Once you do this, set permissions through windows explorer using your root credentials.

Just to confirm, if I apply this to the entire pool, it will not change permissions on .system and break my SAMBA config correct?

Thank you so much for your help. Tell me how I can repay you.

 

[anodos]

Just to confirm, if I apply this to the entire pool, it will not change permissions on .system and break my SAMBA config correct?

Thank you so much for your help. Tell me how I can repay you.

You don't apply it to your entire pool. Just the dataset you're sharing. If you're sharing your entire pool, then you should fix that by creating a dataset with permissions type set to "windows" and share that instead of doing things the way you are right now.

 

[M H]

I have permission type set to "windows" for everything. The pool and every descendant dataset.

 

[M H]

Now, I'm having an issue with many read-only files, one won't even allow me to run a chmod 770 in SSH CLI signed in as root. (getting "Operation not permitted" as root user)

 

[anodos]

I have permission type set to "windows" for everything. The pool and every descendant dataset.

When you create a windows dataset its aclmode is set to "restricted" https://github.com/freenas/freenas/...bb6abb06974b1e84878/gui/storage/views.py#L374

You stated that aclmode was "passthrough", ergo not a windows dataset. There might be something in the backend that prevents changing the aclmode on the root dataset of your pool (the one having the same name as your pool). This most likely prevents you from wrecking permissions on Don't share your entire pool. Create windows datasets and share those instead.

chmod operations do not work on windows datasets. The proper command is "getfacl". If you screw stuff up too royally, you can reset permissions through the webgui for your share (apply default permissions).

You need to figure out why they're readonly. In addition to ACLs, there are DOS attributes. Figuring out whether they are causing your files to be read-only is fairly simple. Apply the following auxiliary parameters to your CIFS config (not share config).

Code:

ea support = no
store dos attributes = no
map archive = no
map hidden = no
map readonly = no
map system = no

If your files are no longer read-only then it's dos modes causing problems. If probelm persists, I recommend resetting default permissions on your share and then re-configuring after verifying that aclmode is set to restricted for the share.

 

[M H]

Ok, will do. I did run one "apply default permissions" before asking for help here. That got me to even be able to change and control Windows ACLS. Should I run it again after checking the aclmodes on my datasets? I just checked all my datasets and they are ALL showing as restricted now. They show source as "inherited from my top level pool." Hopefully, I didn't screw anything up there.

Thank you for your help. This has been a total nightmare and I wish that I just stayed with the reduced functionality of 9.2.1.8. Why did all of these problems show themselves after the upgrade to 9.3? CIFS daemon upgraded?

 

[anodos]

Ok, will do. I did run one "apply default permissions" before asking for help here. That got me to even be able to change and control Windows ACLS. Should I run it again after checking the aclmodes on my datasets? I just checked all my datasets and they are ALL showing as restricted now. They show source as "inherited from my top level pool." Hopefully, I didn't screw anything up there.

You probably haven't, but you should check the aclmode of your .system dataset. It should be "passthrough".

Code:

zfs get aclmode <pool>/.system

Thank you for your help. This has been a total nightmare and I wish that I just stayed with the reduced functionality of 9.2.1.8. Why did all of these problems show themselves after the upgrade to 9.3? CIFS daemon upgraded?

Unix permissions on a CIFS share is an "unsupported configuration". It's unsupported because it tends to be unstable and blow up in unpredictable ways.

 

[M H]

So, my .system is now showing as restricted also. I'm afraid to cycle the CIFS service, because we cannot afford to be down for any time right now.

How should I proceed?

Also, I haven't cycled the CIFS service since I ran "apply default permissions" on the CIFS share yesterday. I know when I did this in 9.2.1.8, it completely bricked my Samba config.

I did read somewhere that 9.3 was supposed to prevent you from changing permissions on the .system dataset however.

EDIT: I should say that I ran for the past year without issue running Unix permission on a CIFS share. This was partially the reason I upgraded, because I didn't want unexpected surprises, but this has turned for the worse.

 

[anodos]

So, my .system is now showing as restricted also. I'm afraid to cycle the CIFS service, because we cannot afford to be down for any time right now.

How should I proceed?

EDIT: I should say that I ran for the past year without issue running Unix permission on a CIFS share. This was partially the reason I upgraded, because I didn't want unexpected surprises, but this has turned for the worse.

zfs set aclmode=passthrough <pool>/.system

 

[M H]

Thank you. .system now shows as passthrough. Am I safe to cycle the CIFS service after this change and what I mentioned above?

Your numerous posts on Windows ACLs have been invaluable.

 

[anodos]

Thank you. .system now shows as passthrough. Am I safe to cycle the CIFS service after this change and what I mentioned above?

Your numerous posts on Windows ACLs have been invaluable.

If things are in a working state right now, I'd wait to cycle the CIFS service. Otherwise, it's probably safe to cycle. You can run "testparm" from the CLI to see if it detects any permissions issues in samba backend / tdb files just to be certain.

 

[M H]

No errors it seems in testparm. Should there be an issue when I cycle tonight, is the general consensus to just destroy the .system dataset and let it regenerate?