Hi everyone,
I have found a fix for this issue that allows you to maintain 775 permissions (does not allow
everyone to write to your folders.)
As far as our network configuration, we have a Windows Server running Active Directory, a Linux Centos file server that hosts our files to the network via Samba, and Windows clients that access the Samba share in their various DCC applications.
For us, the issue was that the permissions between our Windows AD->Linux->Windows were not cleanly being passed between the different OSes. USD uses the Win32 API under the hood to determine if a Windows User has permissions to write to any given directory. This API requires that the permissions across these different OSes are clearly communicated. All we have to change is settings on our Centos file server to map all of the permissions correctly.
You shouldn't have to restart your File Server for any of these fixes to work, but you may need to leave and join the domain, so expect for your file server to go down for a bit.
MAKE SURE TO REPLACE ANYTHING IN <> IN THE BELOW CODE WITH THE VALUES SPECIFIC TO YOUR NETWORK. ALSO IF NOT RUNNING CENTOS 7, YOUR COMMANDS MAY DIFFER SLIGHTLY.
STEPS TO FIX:
You will start by ssh-ing as root (if not connected to the domain) into the Linux machine that you are trying to host a Samba share on.
If you have already connected the machine to the AD skip to step 5.
If you already have Samba running on the Linux machine but are having issues with permissions, skip to step 9.
To connect to the network, we will use the preinstalled realm package. To check if you are already connected, use the command realm list. If you get anything returned here, you are connected to the domain already, otherwise you need to join the AD.
To join the AD, type realm join -U <your domain username> you will be prompted to enter your password. This should take a few seconds, and afterwards, a realm list should show you successfully connected to the AD.
You should at this point be able to ssh into the Linux machine as a domain user. Verify that you can do this before continuing.
Once connected to the AD, run a yum install samba samba-common. Install all dependencies as needed. This should includes packages such as sssd and samba and will setup the basic samba config directory (/etc/samba/*).
At this point, you will want to ensure everything installed correctly and nothing is corrupted by doing a:
systemctl start smb nmb winbind.
(There should be a warning about the system not being able to find winbind yet, we will install that later).
If you got any errors here, check the logs for the respective service and debug. Otherwise, check the status of the services with:
systemctl status smb nmb
If everything is working, you should be able to see your user's Linux home directory from Windows by using Windows explorer to navigate to the hostname like so:
\\<hostname>
Now we will update the /etc/samba/smb.conf file to fix the permissions issues we are having. Open this file with your preferred text editor, I use vi because it's preinstalled and is simple to use, but you can use whatever. Update the file to look like this:
[global]
workgroup = <DOMAIN NAME>
security = ADS
realm = <DNS name of the Kerberos Server>
passdb backend = tdbsam
kerberos method = secrets and keytab
idmap config * : backend = tdb
idmap config * : range = 3000-7999
idmap config <DOMAIN NAME>:backend = rid
idmap config <DOMAIN NAME>:range = 10000-999999
template shell = /bin/sh
template homedir = /home/%U
winbind refresh tickets = yes
vfs objects = acl_xattr
map acl inherit = yes
acl_xattr:ignore system acl = yes
disable spoolss = yes
printcap name = /dev/null
load printers = no
cups options = raw
# Here you will set the share name/comment/path and read only state. Don't set anything else here.
[testshare]
comment = Test Share
path = /test
read only = False
Important things to know about the changes we made:
- Set the kerberos method so auth is secure
- Set the ID mapping to rid so that Winbind can translate the UIDs/GIDs back to Windows.
- Set the template shell/homedir so that we retain individual user home dir and I believe template shell is required?
- Set winbind to refresh tickets because otherwise they expire after a day or so
- The three lines below winbind refresh tickets = yes are also ?required? for translating UIDs/GIDs back to Windows? Need to test this for sure
- At the bottom section of global we disable printing.
At this point you should be able to restart samba and everything should still work. You should be able to access the share (folder under the testshare section) from Windows. You will again use Windows Explorer to test this via \\<linux machine name>\<share name>. If this doesn't work you have messed something up. I would start with checking that sssd, smb, nmb services are all running.
At this point, if you run the command id in Linux, you will likely see your ID is very large (See Figure 2). This means that the IDs are not correctly mapping from
Windows->Linux. This is expected behavior. We have a few more steps to do.
Next we need to install winbind this is the service that handles mapping the Linux UID/GIDs back to Windows SIDs so that Windows apps using the Win32 API can correctly verify your user's permissions. To install this use the command:
yum install samba-winbind
In order to use a helpful winbind debugging utility called wbinfo (I won't go into how to use this for debugging), you should also run:
yum install samba4-winbind-clients
Now, winbind is ready to use as a service, but is not plugged into anything. Therefore if we started the winbind service, winbind would have no valid configuration and would actually block access to the share. So first we need to actually tell the Name Service Switch (NSS) to actually use winbind as a name resolver. To do this open up the /etc/nsswitch.conf file and edit these two lines:
passwd: files sss
group: files sss
to look like this:
passwd: files winbind sss
group: files winbind sss
After making this change, you do not need to restart/reload any services, as nsswitch is just an API for C libraries.
There is one other change that we must make in order to make the ID mapping work properly. This is currently unconfirmed if this actually affects anything, but AFAIK it is necessary. Open up the file /etc/sssd/sssd.conf and add the line:
ldap_idmap_autorid_compat = True
Supposedly this line makes it so SSSD and Winbind interact correctly and pass off IDs as intended.
After making this change, make sure to reload the sssd service via:
systemctl restart sssd
Lastly you should make sure smb, nmb, winbind, and sssd are all started up and running with no issues via:
systemctl restart smb nmb winbind
systemctl status smb nmb winbind sssd
After making all of the previous changes, you should be able to exit the Linux machine and ssh back into it (with your domain login) without any issues. If not you have messed something up.
Upon logging in, should be given the sh shell as defined in the above samba config and you should be able to run the id command and should get both User IDs and Group IDs that are in the 10000-999999 range (from the samba config). You should also see that the user and group names returned from the id command include the actual domain name in them Ex. (<DOMAIN NAME>\<DOMAIN USERNAME>). If all of these things looks right, you've successfully setup ID mapping for Samba!
Now that the mapping is working, you will need to use the new domain UIDs/GIDs for any existing folders on the share that you want to fix the permissions issues on. To do this you can run the chown command. For example, you can change the ownership of the root share folder (in this case /test) like this:
sudo chown <DOMAIN NAME>\\<DOMAIN USERNAME>:<DOMAIN NAME>\\<DOMAIN GROUP NAME> /test
You
must use the above syntax <DOMAIN NAME>\\<DOMAIN USER/GROUP NAME> rather than the email <DOMAIN USERNAME>@<DOMAIN EMAIL>.com" when changing ownership or it may use the OLD UIDs/GIDs for the groups (the really high number ones) instead. The really high number ones will not work in Windows.
COMMON ISSUES
On the Linux side, the id's for groups are not mapping? For instance when ssh as a domain user into the Linux machine, I see this message:
/usr/bin/id: cannot find name for group ID 10513
To fix this, check your /etc/nsswitch.conf and ensure that you set only these lines to include winbind:
passwd: files winbind sss
group: files winbind sss
Please note that the shadow entry (that is in between passwd/group does not include winbind.
You may have issues when turning on winbind where when exiting ssh and rejoining, your ID is still not correctly falling within the range. To fix this, you should try leaving the realm, and rejoining it. This seemed to force rebind to recalculate ids correctly.