Since writing this post, these subsequent posts may help with some issues:
- How to remove .DS_Store and other system-created files in Samba
- Issues with PBIS Active Directory and Samba
Introduction
One of the many servers we didn’t lose was the team’s storage server, called Warehouse. In fact, it was the only remaining survivor of what we can in future call the Great Server Loss of 2014 (or 2015. We’ve had two now). However, it had been set up by someone else who worked here and I was keen to see how hard it was to set up for myself, since we’ll be setting something similar up later for students to have their own storage space. With the server’s footprint at over 2TB (deleted files don’t free up any usage, since its a VM), I decided it would just be quicker and more useful to rebuild it from scratch, rather than copy everything over to a new partition in a lengthy disk “downsize” process.
This – and following – articles should help with making a file server in Ubuntu (the same steps should more or less apply to any other flavour of Linux) that you can then access, and map a drive to, from Windows. We need Samba because Linux’s own file system, NFS, can’t be accessed natively by Windows – so we will configure a system that can. Samba is, basically, the Unix way to to use Server Message Blocks (SMB), which is mostly used by Microsoft networks for file-sharing and communication between hosts. If you’ve seen the term CIFS anywhere, it is basically a Microsoft-only implementation of an older (but once newer) version of Samba (see here for a more in-depth explanation of how it all fits together). So Samba is the thing we will configure and use for Windows machines to be able to access the file system on our Linux server – from Windows, it should essentially appear to be just the same as a Windows server share.
For where I work, there are two purposes for our storage server:
- Share files between staff members in Windows, which should be only accessible by certain authenticated users
- Make certain files (desktop backgrounds, some installers, some documents and assets) publicly accessible for other users and computers
There are a few steps involved and, although not particularly lengthy, I wanted to go into a bit more detail about how to get each step working and explain some of the problems you might also face in a similar environment.
Initial Installation
When installing a standard Ubuntu 14.04 server installation, select Samba and OpenSSH. Out of the box you can connect to the server via SFTP, using something like WinSCP. But this isn’t really practical for accessing files – additionally, you have to be authenticated to login and, with only one account, you’d have to make more users manually if you wanted to give access to different people. So, after updates and upgrades, we need to configure Samba to make it work at all and end with the aim of joining an Active Directory domain.
Configuring Samba
There are two things that are implied a lot throughout the next few step;s the first is that you are editing the samba configuration file which in this case – unless otherwise specified – is at /etc/samba/smb.conf
The second thing is that you will be doing a lot of service restarts. Any time you make a change in the Samba configuration file, you have to restart both the nmbd and smbd services, which you can do using service samba.
Finally, you’ll likely have to use sudo for everything.
sudo vim /etc/samba/smb.conf sudo service samba restart Stopping Samba daemons: nmbd smbd. Starting Samba daemons: nmbd smbd.
Starting to make Samba work
Now, by default if you connect to a Ubuntu server through the Windows explorer address bar, for example \\10.1.63.246\, you’ll get a message that Windows can’t access the address. However, with Samba installed, you’ll be able to browse it straight away, since ports 139 and 445 are open, which are used by Samba. Although, until we enable the home directories, we won’t see anything.
The first thing to do is edit the samba configuration file, smb.conf, which contains different categories and settings. There will be a commented out section called [homes], so uncomment it to read as follows:
[homes] comment = Home Directories browseable = yes
If you save and exit the configuration and restart the samba service, you can now navigate back to your IP address and should see new folders show up:
This will show whether or not it works! However, you don’t need be authenticated for this and, by default, all user directories are shown here and, although not editable, they are readable and copyable. In the configuration file, you can change “browseable = yes” and make it “no” instead; this way, you can’t see all the home directories by default and any other shares you make, you can make browseable. However, the user directories are still accessible. This probably still isn’t going to be quite right; we want to create our own shares and control which are public and which require a user to be authenticated to be able to view them.
Active Directory with PBIS
One way to accomplish this is to make different user accounts and groups on the server itself, but with an Active Directory domain already in existence, we can just join our server to the domain, as previously described here, under “Change 2”, and use these accounts and groups instead.
With the server on the domain, you can now login as other users if you wanted to. I modified the configuration file to remove all of the comments and, essentially, rewrite it as follows;
[global] workgroup = Troliver realm = troliver.com server string = Warehouse Server (%h) dns proxy = no security = ADS encrypt passwords = true log file = /var/log/samba/log.%m max log size = 1000 syslog = 0# panic action = /usr/share/samba/panic-action %d passdb backend = tdbsam obey pam restrictions = no unix password sync = yes passwd program = /usr/bin/passwd %u passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n$ pam password change = yes
The important things here are the domain name in realm and that security = ads is set. After this comes the different shares – mappings to Unix directories; to make a share, you have to specify the path to a directory.
Creating shares
For this guide, I’ve made two shares – test1 and test2. You can do this by simply add the following lines to the configuration file created above:
[test1] comment = Read only, everyone path = /home/share/test1 [test2] comment = Read only, CST Tech Staff group path = /home/share/test2
The shares will be visible but you can’t initially access them, with a message that the network name cannot be found.
This is because the path we have specified in Samba doesn’t actually exist on the server. Samba will show Windows that this path exists but that doesn’t necessarily mean it does; samba acts a front end to Windows and the configuration tells samba, essentially, how to present your server to the rest of the network.
To resolve this, we just create a new folder with mkdir and it should now work:
mkdir /home/share/test1 mkdir /home/share/test2
Restricting shares to specific users or groups – Samba permissions
The next thing we can do is to restrict who can actually access the share. We can specify that “test2” can’t be accessed by anyone who isn’t called “testuser1”
[test2] comment = Read only, access only Staff group path = /home/share/test2 valid users = testuser1
Alternatively, we can specify a group name by prefixing it with an @, as below:
[test2] comment = Read only, access only Staff group path = /home/share/test2 valid users = @domain^admins
Now we are giving a whole group – domain^admins – access to the share instead. You’ll notice that, if you aren’t logged in, you cant access it; but you can still see it if you browse to the address of the samba server. By default, without valid users specified, everyone is able to access the share.
The last thing to put in, which we will need later, is to make any new files created by a user to be given a specific group association with force group.
[test2] comment = Read only, access only Staff group path = /home/share/test2 valid users = @domain^admins force group = domain^admins
Normally, in our domain, it seems that any files created from within Windows by an authenticated user will be created with “domain^users” as the group; but the problem is that this would include anyone who isn’t in the group of domain^admins if they were a member of both. The above change in the configuration forces all files to take on their group membership of domain^admins and, if necessary, “force user” can be added, too, to force ownership of the file by another user.
Edit: There is an important thing to note here. If you want a share to only be accessible by a specific group – say domain^admins – you may have to prefix it with a plus sign (+domain^admins) if you don’t also specify “valid users”:
In Samba 2.0.5 and above this parameter has extended functionality in the following way. If the group name listed here has a ‘+’ character prepended to it then the current user accessing the share only has the primary group default assigned to this group if they are already assigned as a member of that group. This allows an administrator to decide that only users who are already in a particular group will create files with group ownership set to that group. This gives a finer granularity of ownership assignment. For example, the setting
force group = +sysmeans that only users who are already in group sys will have their default primary group assigned to sys when accessing this Samba share. All other users will retain their ordinary primary group.
Restricting shares to specific users or groups – Unix permissions
(For a quick explanation of Unix permissions, see my previous article on Unix permissions.)
As I mentioned earlier, Samba relies on the underlying Linux system to have directory availability and permissions to match that which it advertises; in other words, the Linux file system is what really counts here. You can create a share to anywhere, but if that folder doesn’t exist on the system, then it won’t ever be accessible. Similarly, even if you restrict access to a share through Samba’s permissions, there is no guarantee that somebody might not gain access via SSH and access folders that way.
Since you have to ensure that the underlying shares that Samba can access have the right permissions anyway, you might as well restrict who can access a folder this way too.
First of all, we need to change the group that owns the folder, which isn’t a Samba-specific thing. You can check the owner and the group of a file or folder with ls -l.
Then use the following command to change the group to domain^admins:
chgrp domain^admins /home/share/test2
Check the ownership again:
The test2 share should now be accessible by the domain^admins group, however nothing will have necessarily changed, since the default permissions for that directory is 755; which means only the owner can modify files, but everybody else can only read and execute them; including the group assigned to it.
However, this isn’t necessarily too problematic at the moment because newly created files still are only modifiable by their owner, as per the underlying Unix file permissions. But non-authenticated users can view the newly made files and only the owner can modify them, which isn’t necessary what we want; we want the owner and the group to be able to read and write and everyone else to have no access at all.
So to do that, we want this changed with chmod to 770 or 775 – which means that the group associated with a directory, or file, has the same permissions as the owner, whilst still restricting the access of other users. This is an important step to follow, otherwise your restrictions won’t apply how you want them to.
chmod 771 /home/share/test1 chmod 770 /home/share/test2
This needs to be done for the main directories that you want to act as shares. I would recommend setting them to 775 for public folders and 770 for restricted folders, with the group set to being that of one that you wish to act as administrators for the folders. But there is another issue; even if we have the share folders’ permissions set and the users and groups of new files set to those that should have appropriate access, we don’t have the default permissions set to match them.
Back to Samba again
However, from within Samba, we can force a set of permissions for files and directories with two sets of commands;
- create mask and directory mask
- force create mode and force directory mode
These can be used to specify what permissions are granted to new files when they’re created. There are some default behaviours, by default:
- Samba’s default create mask is 744 and directory mask is 755
- Samba’s default force create mode is 000
- Samba ignores the system umask (which is 0022), which is used to give permissions to files normally
Logically, the way in which permissions are changed by these two sets of commands are (with this site backing it up),
- force create mode will do a logical OR on permissions, so modification should increase permissions
- create mask will do a logical AND on permissions, so modification should restrict permissions
Therefore, I would likely need a combination of both; force create mode to increase permissions for the group and create mask to remove permissions for other users. Because the create mask already has a default, we should just be able to change that to remove the restriction that is inherent with its use. However, even after setting create mask to 777, which should get rid of any restrictions, this actually only sets the permissions to 766 for new files instead – and it doesn’t seem that there is any logic for this to be happening at all. If the system umask and fmask did actually affect these files, then my setting it to 0000 would have had some affect, which it didn’t. It looks like there is something else restricting the permissions, somewhere else; however this isn’t a big deal, since we don’t necessarily want everyone to execute files on the server. So we can stick with the following additions to the file to make files only read/write by the group assigned to that file or directory with:
create mask = 0660 directory mask = 0770
Amend for public readable files and folders with:
create mask = 0660 directory mask = 0770
So no matter what we do with create mask, we are restricted to not being able to execute for group members or other users. But here’s the thing; you can force Samba to give you all the permission you want if we then decide to user force create mode – you can get the last two bits you need with setting it to 011 (or 777, for that matter), although I don’t see what is preventing you from doing this same thing by removing the create mask by setting all permission bits. Feel free to contact me if you have any idea why!!
So with that finally done, here is the resulting smb.conf file that should give you access to a shared directory that has had its permissions set to 770 and its group assigned to domain^admins. Note that, if you only need one group to be able to access the share, you don’t need to include the valid users line, since this is just a Samba restriction – if the underlying file system already has that restriction, its redundant. Uncomment or keep commented as necessary.
[test2] comment = Read only, access only Staff group path = /home/share/test2 #browseable = no #valid users = @domain^admins force group = domain^admins create mask = 0740 directory mask 0750
What next?
- These three options shouldn’t need to be configured, but you might
want to if you have a larger group given access that might include other
groups, or you want to restrict access without using ACLs:
- guest ok
- write list
- valid users
- For more information on getting started and configuring Samba for Ubuntu, take a look at a few of the guides on the Ubuntu page for Samba as well as some of the following links, which helped me too:
If you have any comments or questions, feel free to post them below. I may well have overlooked something!
No comments:
Post a Comment