SMB disaster

Status
Not open for further replies.

Tweebeenvis

Dabbler
Joined
Sep 28, 2016
Messages
10
Hi All,

I've been running FreeNAS with Windows AD integration successfully for almost a year now. AD users had their own shares which they could add/delete files and AD domain admins also had full control (being the admin group). Disaster struck Monday and I am still picking up the pieces. I am convinced that one of the admins changed the top level share and reset the permissions. No matter what I did, domain users could not get into the shares.

I eventually ended up switching to an rsync backup of the files with critical company files moved to basic password protection. Rsync saved my job :D Anyway....

After giving up with getting the ACL's working I tried reverting back to UNIX permissions - Yes, I know. In any event things aren't looking good.

The main "Users" share is now owned by root:wheel with permissions 777 and allowing guest access. I can view the files fine but cannot write to any of the directories. ACL's where still present but were stripped with find Users -exec setfacl -b {} \;

"Users" (and all subfolders )permission is now: drwxrwxrwx 97 root wheel 97 Mar 1 09:26 Users/ But I cannot write/delete anything from folders.

I've Googled for hours but cannot determine what the issue might be.

I would appreciate if someone could:

1. Shed some light on my current predicament
2. Recommend a best practice guide for running FreeNAS in an AD/SMB environment (I thought I was doing quite well until Monday)
3. Advise whether there is a way to sync Windows/ACL permissions with Rsync backups

I'm running the latest version of FreeNAS stable.
 
Last edited by a moderator:

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,546
Hi All,

I've been running Freenas with Windows AD integration successfully for almost a year now. AD users had their own shares which they could add/delete files and AD domain admins also had full control (being the admin group). Disaster struck Monday and I am still picking up the pieces. I am convinced that one of the admins changed the top level share and reset the permissions. No matter what I did, domain users could not get into the shares.

I eventually ended up switching to an rsync backup of the files with critical company files moved to basic password protection. Rsync saved my job :D Anyway....

After giving up with getting the ACL's working I tried reverting back to UNIX permissions - Yes, I know. In any event things aren't looking good.

The main "Users" share is now owned by root:wheel with permissions 777 and allowing guest access. I can view the files fine but cannot write to any of the directories. ACL's where still present but were stripped with find Users -exec setfacl -b {} \;

"Users" (and all subfolders )permission is now: drwxrwxrwx 97 root wheel 97 Mar 1 09:26 Users/ But I cannot write/delete anything from folders.

I've Googled for hours but cannot determine what the issue might be.

I would appreciate if someone could:

1. Shed some light on my current predicament
2. Recommend a best practice guide for running Freenas in an AD/SMB environment (I thought I was doing quite well until Monday)
3. Advise whether there is a way to sync Windows/ACL permissions with Rsync backups

I'm running the latest version of FreeNas stable.
PM me a debug file and I'll take a look at it.

BTW, "UNIX permissions type" on samba shares is an unsupported configuration.

This has different implications for home users and for business users. "Unsupported" can be interpreted as "may break at a future time, and if it does, don't expect developers to fix it".
 
Last edited:

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,546
Hi All,

I've been running Freenas with Windows AD integration successfully for almost a year now. AD users had their own shares which they could add/delete files and AD domain admins also had full control (being the admin group). Disaster struck Monday and I am still picking up the pieces. I am convinced that one of the admins changed the top level share and reset the permissions. No matter what I did, domain users could not get into the shares.

I eventually ended up switching to an rsync backup of the files with critical company files moved to basic password protection. Rsync saved my job :D Anyway....

After giving up with getting the ACL's working I tried reverting back to UNIX permissions - Yes, I know. In any event things aren't looking good.

The main "Users" share is now owned by root:wheel with permissions 777 and allowing guest access. I can view the files fine but cannot write to any of the directories. ACL's where still present but were stripped with find Users -exec setfacl -b {} \;

"Users" (and all subfolders )permission is now: drwxrwxrwx 97 root wheel 97 Mar 1 09:26 Users/ But I cannot write/delete anything from folders.

I've Googled for hours but cannot determine what the issue might be.

I would appreciate if someone could:

1. Shed some light on my current predicament
2. Recommend a best practice guide for running Freenas in an AD/SMB environment (I thought I was doing quite well until Monday)
3. Advise whether there is a way to sync Windows/ACL permissions with Rsync backups

I'm running the latest version of FreeNas stable.

The procedure to generate a proper debug file is to click "System" -> "Advanced" -> "Save Debug".

The files that you sent me indicate that your server is no longer joined to your domain. It is possible that there was a change in your domain that is preventing FreeNAS from joining it. I can't tell you more without seeing a full debug file.

An example of a change in a domain that would cause older versions of FreeNAS to be 'dropped' would be disabling SMB1 support. Old versions of Samba use SMB1 connections to IPC$ on the DCs to join the domain (DCERPC tunneled over SMB1). This is fixed by upgrading to the latest stable FreeNAS build.
 
Last edited:

Tweebeenvis

Dabbler
Joined
Sep 28, 2016
Messages
10
Noticed something interesting this morning. It seems that the dataset permissions were in fact correctly updated when removing ACL's with find Users -exec setfacl -b {} \; and setting unix permissions to allow all.

The issue seems to be on the sharing side, if I export the SMB share with the same name ("users") and allow guest access I can open and view all files, I cannot however change or delete any files even though permissions are wide open. When I rename the same exported smb share ("users") as something else (in this case "userstest") I have full access to the files rwx (which is expected with the permissions as set). I've tried on multiple system both on and off the domain - results are the same.

My problem is (If I was still using this NAS) that I would not have been able to rename the share as it would break all user links and shortcuts. I am not sure if this is a smb configuration issue, I cannot reset the nas to factory defaults just yet.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,546
Noticed something interesting this morning. It seems that the dataset permissions were in fact correctly updated when removing ACL's with find Users -exec setfacl -b {} \; and setting unix permissions to allow all.

The issue seems to be on the sharing side, if I export the SMB share with the same name ("users") and allow guest access I can open and view all files, I cannot however change or delete any files even though permissions are wide open. When I rename the same exported smb share ("users") as something else (in this case "userstest") I have full access to the files rwx (which is expected with the permissions as set). I've tried on multiple system both on and off the domain - results are the same.

My problem is (If I was still using this NAS) that I would not have been able to rename the share as it would break all user links and shortcuts. I am not sure if this is a smb configuration issue, I cannot reset the nas to factory defaults just yet.

Name the share "users", then check for the presence of NT-style ACLs on your shares sharesec --view-all then post output here.
The default ACL on a share is ACL:S-1-1-0:ALLOWED/0x0/FULL
 
Last edited:

Tweebeenvis

Dabbler
Joined
Sep 28, 2016
Messages
10
Interesting - The ACL is set to ACL:S-1-1-0:ALLOWED/0x0/READ

Why would this not be reset to FULL after stripping ACL's and setting recursive permissions in the webgui?
 

Tweebeenvis

Dabbler
Joined
Sep 28, 2016
Messages
10
I see. I tried looking at the sharesec command - How would I go about setting the ACLs back to the default "FULL"?

Thanks for all the help, much appreciated.
 

Tweebeenvis

Dabbler
Joined
Sep 28, 2016
Messages
10
I added ACL with the -a flag (as per documentation):
sharesec Users -a S-1-1-0:ALLOWED/0/FULL

Then ended up with both FULL and READ ACLs, I removed the READ with:
sharesec Users -r S-1-1-0:ALLOWED/0/READ

I seem to have full access to the files now. One thing I did notice when running sharesec --view-all is that all shares that where set up with no permissions have a line showing CONTROL: SR|DP and the "Users" share has an extra DR as in CONTROL: SR|DR|DP is this cause for concern? I can't find much on Google regarding this.

Found this quite useful:
https://www.systutorials.com/docs/linux/man/1-sharesec/
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,546
I added ACL with the -a flag (as per documentation):
sharesec Users -a S-1-1-0:ALLOWED/0/FULL

Then ended up with both FULL and READ ACLs, I removed the READ with:
sharesec Users -r S-1-1-0:ALLOWED/0/READ

I seem to have full access to the files now. One thing I did notice when running sharesec --view-all is that all shares that where set up with no permissions have a line showing CONTROL: SR|DP and the "Users" share has an extra DR as in CONTROL: SR|DR|DP is this cause for concern? I can't find much on Google regarding this.

Found this quite useful:
https://www.systutorials.com/docs/linux/man/1-sharesec/

Actually, samba will fake-up an "Everyone-FULL" ACL in the absence of an entry in the share_info.tdb file. So, the process for restoring to sane default is just a matter of deleting the security descriptor for the share sharesec -D ShareName. Another one of those Samba features that's only documented in the source code. :D Yay!

Note that if this was your ACL the whole time (i.e. Everyone-read-only), then it might account for a lot of your permissions problems.
 

Tweebeenvis

Dabbler
Joined
Sep 28, 2016
Messages
10
I have no idea what it was before everything went to crap and still no idea what could have been the reason the whole thing came down. I just know I never want to go through this again :D Is there a recommended best practice guide of setup for integration with SMB and AD? I've seen a few videos but nothing as in-depth as I require. I might have to set up a windows file server to avoid all these ACL issues :(:(:(

Thanks.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,546
I have no idea what it was before everything went to crap and still no idea what could have been the reason the whole thing came down. I just know I never want to go through this again :D Is there a recommended best practice guide of setup for integration with SMB and AD? I've seen a few videos but nothing as in-depth as I require. I might have to set up a windows file server to avoid all these ACL issues :(:(:(

Thanks.

The debug file you sent me was a little too old to pinpoint what exactly went wrong with your permissions. If it is due to a sysadmin doing something screwy like resetting permissions to default, then there's not much to fix (other than take away sharp knives - prevent access to the WebUI and have them administer via "computer management").

On the other hand, if you're using "Unix permissions" type on a samba share in an AD environment, you're asking for trouble. This configuration is known to cause inexplicable permissions problems. That's the reason why iX systems has labelled it an "unsupported configuration".

If it happens again, immediately generate a debug file. Then you will be able to review the nginx access log and see if the incident corresponds with someone using the webui.
 

Tweebeenvis

Dabbler
Joined
Sep 28, 2016
Messages
10
I was not using Unix permissions on the shares - All AD shares where set to windows. I also read that nesting of datasets with different permissions is not advised. Not that I was doing this, but just wanted to double check, If I create a volume called "tank01" a dataset called "tank01" is automatically created (with default linux permissions). If I then create a dataset under this called "users" and give it windows permissions is this standard/acceptable practice? (all newly created datasets have default linux permissions anyway).

Thanks.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,546
I was not using Unix permissions on the shares - All AD shares where set to windows. I also read that nesting of datasets with different permissions is not advised. Not that I was doing this, but just wanted to double check, If I create a volume called "tank01" a dataset called "tank01" is automatically created (with default linux permissions). If I then create a dataset under this called "users" and give it windows permissions is this standard/acceptable practice? (all newly created datasets have default linux permissions anyway).

Thanks.

It should work fine. In an AD environment, I try to set the owner / owner group for samba shares in the UI to "<a specific admin account>:wheel". Then I use computer management while logged in as that admin user to add a "Full Control" ACE for Domain Admins and additional ACEs for domain groups that need access (as well as remove the "Everyone" ACE). This is because the owner / owner group ACEs correspond to the special Owner@ and Group@ aces (which can change values). Using non-trivial ACEs to control access is much more stable in the long-run as someone using chrgrp from the CLI won't totally bork your permissions.
 

Tweebeenvis

Dabbler
Joined
Sep 28, 2016
Messages
10
Great, thanks. I will do exactly that. On the windows share side, I've logged into a domain pc as my nasadmin user and went to computer management "connect to another computer" I went to my nas and then "shares" my shares are showing up fine. When I go to properties of the share I get "Share Permissions" and "Security" where should the domain admin and groups be added? - I used to do this straight on the share :D

Thanks.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,546
Great, thanks. I will do exactly that. On the windows share side, I've logged into a domain pc as my nasadmin user and went to computer management "connect to another computer" I went to my nas and then "shares" my shares are showing up fine. When I go to properties of the share I get "Share Permissions" and "Security" where should the domain admin and groups be added? - I used to do this straight on the share :D

Thanks.
Security. You should make sure that permissions are in a consistent state before doing this, which is a 2-step process:
1) in the dataset portion of the webui (under "storage" -> "volumes"), recursively apply permissions.
2) in the samba share portion of the UI (under "Sharing" -> "Windows (SMB) Shares"), check 'apply default permissions' and click 'OK'
 
Last edited:
Status
Not open for further replies.
Top