Preparing for sharing
Last time we talked about setting up a large partition for storing data, and mounting it at /mnt/data. But we didn’t do anything with this directory and left it to the installer to set it all up. If running the command: $ grep /mnt/data /etc/fstab doesn’t return anything and you haven’t explicitly set up your own storage drive/partition, then you’ll need to do this now, since this is the directory we’ll be sharing over Samba. The command lsblk will display a list of drives and their partitions. You won’t be able to operate on the drive containing the OS from here, although it is possible to reshuffle things and add the requisite data partition from a live medium. So let’s say you’ve just installed a drive /dev/ sdb and want to use all of it for the data partition. First the drive must be partitioned, which we can do with sudo fdisk /dev/sdb . Enter p to display the partition table. If there are other partitions on it, it’s a good idea to check that there’s nothing important on them beforehand. Assuming that’s not the case summarily delete all of them by entering d as required. Now create a new partition by entering n and accepting the defaults. Then write the partition table by entering w . Before it can be used, the partition must be formatted. We’re going to use the ext4 filesystem, which is a good choice unless you have a particular reason for choosing something more exotic. Take extra care when typing this command because it will delete everything on the target partition and the chances of recovering it are miniscule: $ sudo mkfs.ext4 /dev/sdb1
Now we need to tell Debian to mount this filesystem on every boot. The command sudo blkid will list all block devices together with their UUIDs (which have the advantage of never changing even if other drives are added/removed, unlike the device nodes sdb1 etc). This next step is much easier if you’re SSHing into your server from a desktop environment with cut and paste functionality [New fangled clipboard frippery... didn’t have that in my day – Ed]. Copy, make a note of, or memorise the relevant UUID. Then edit the filesystem table with: $ sudo nano /etc/fstab
Add a line of the form UUID=“abcdef01-2345-6789-abcd-ef012345678” /mnt/data ext4 defaults 0 0 pasting/regurgitating the UUID from earlier, and save and quit with Ctrl-X, Y, Enter. We can now mount our data partition with a simple: $ sudo mount /mnt/data
Let’s make an incoming share inside this directory. We shall give this directory rather permissive permissions, since we want to make it writeable to guests through Samba so that anyone can upload (but also anyone can delete things). $ sudo mkdir /mnt/data/incoming $ sudo chmod 777 /mnt/data/incoming
We’ll also change the ownership of /mnt/data, which will allow privileged users write access to this directory as well as to incoming/.
Our next task is to install the subjects of this episode, Samba and Webmin. Details of how to do just that can be found in the box at the top of the page. Once this is done we should see a message saying we can now login to Webmin on https://lxfserver:10000/ This is not strictly speaking true, however, since the rest of our network doesn’t know our server’s hostname. Rather than opening a whole hostnamerelated can of worms, let’s just pretend the message in fact said that we can now login on https://192.168.1.100:10000,
remembering that this was the IP address we assigned our server last time (obviously change it to suit your configuration). It’s not all plain sailing, (where would be the fun in that?) since if you try to visit that page you’ll be met with an invalid certificate warning. While it’s normally a terrible idea to ignore these, in this case it’s fine to do so, since we’ve already implicitly consented that this is our server’s address when we SSH’ed in to install all those bits earlier. Web browsers make it hard to get around this warning, but there is always a way, if you follow the small print. In Chrome/Chromium, this involves selecting Advanced > Proceed to 192.168.1.100 (unsafe). In Firefox things are similar: Advanced > Add Exception > Confirm Security Exception, with the option to permanently store this site so that you aren’t bothered again.
There’s lots to explore in Webmin, some highlights can be found in the box on the opposite page, but let’s get on with the task in hand first. Samba configuration is done from the Servers section of the left-hand column, under Samba Windows File Sharing. Select Create A New File Share from the top row. In the Share name box, enter data and in the directory box below enter /mnt/data . Decline the “Automatically create directory” offer below, since we just did this, and ensure Available and Browseable are both enabled. In the Share Comment box, enter something informative or amusing, and then click Create. Your share should now be visible on the network, which you can verify by opening a file manager, pressing Ctrl-L and entering smb://192.168.1.100 . You should then be able to connect to the data share as a Guest (no password required) and browse the incoming/ directory therein. You might see a lost+found folder inside the data directory, this is created with a new filesystem and is used to store wayward file fragments abandoned in ungraceful shutdowns. Don’t worry about it. What we won’t be able to do, even though we might like to, is create directories or put files into our incoming/ directory.
This is because Samba has its own permission mechanisms, and actually its own user directory, that work independently of Linux’s native constructions. In order to write inside a Samba share, that share must be explicitly marked as writeable. As you would hope, Samba does respect Linux directory permissions too, so these must be set appropriately (as we have done). Return to the data share in
Webmin and go to the Security and Access Control menu. Activate the first option, Writeable, and press Save. You may need to disconnect and reconnect to the share for this to work (Gnome has an eject button next to the share in the lefthand column), but you should now be able to write with impunity inside the incoming directory. Test this by creating a folder or pasting a file from the file manager. Now try it from within the data share itself. It doesn’t work, or at least it shouldn’t. Despite the share being set as writeable, the underlying directory permissions prevent the default Samba user (which gets mapped to the “nobody” account on the system) from writing there, hence the error. We don’t want any old Thomas, Richard or Harold to be able to write (and especially to delete) stuff here, so this is A Good Thing. However, it would be nice if we could log in with a non-guest account in order to populate this share.
This is where Webmin really comes into its own. As we mentioned earlier, Samba users are distinct from normal user accounts on the system. You can define new ones and mappings between the two sets by fiddling around with text files, but it’s easier to let Webmin do this fiddling for us. From the Samba section in Webmin, choose Convert Users. For simplicity we’re just going to mirror our lxfuser on the Samba side, so select the top box (Only listed users…) and enter lxfuser in the adjacent box. The click Convert Users and return to the share list. Now in the Samba Users section
lxfuser should be listed. Our work is not done, since new versions of Windows, and Samba by default, (sensibly)
require encrypted passwords, so our current password (or indeed any password) can’t be migrated to the Samba user automagically. So click on “lxfuser”, move the radio button to New Password, enter your desired password and click Save.
To test the new account we need to reconnect to the share with it. In theory, you can use the syntax smb://lxfuser@
192.168.1.100 here, which should prompt you for a password. However, it seems (at least using Gnome) that it’s hard to log in with different credentials sometimes, so you may need to log out and log back in to your desktop environment in order to test this. Assuming you can find your way back to the login dialogue, this time select Registered User, and use “lxfuser” with the corresponding password. This time you should find yourself able to create files and directories in the data/ share as well as in incoming/.
Windows 10 is rude to guests
Our newly established network share should be visible from clients connecting from all manner of devices. If it doesn’t show up in Windows, you can use the notation \\192.168.1.100 to connect from Explorer. However, with Windows 10 (or at least recent builds of it) you will find that you are unable to connect as a guest since this functionality has been disabled for security reasons. On a home network this is not a problem, but Microsoft’s reasoning is that machines attempting to automatically connect to these shares when on other networks could be tricked into connecting to hostile servers instead. As we’ve seen, it isn’t particularly hard to protect your shares with a password and if we wanted to be rigorous about it then we should do this with all of them. But the convenience of not having to enter a password is nice too, and you can get it back by adding a registry key on the Windows machine, see http://bit. ly/1Y44geP for details.
On the subject of security, we really should stop Samba from listening on the IPv6 interface. We can do this by adding the following lines to /etc/smb.conf: interfaces = 192.168.1.100 bind interfaces only = Yes
And that more or less concludes things for this tutorial, stay tuned for the next exciting chapter in our server series. Alternatively, if you can’t wait, consider investigating adding your own services to the server. A lot can be done from Webmin, but don’t feel restricted by it. You can easily set up a Samba share to share music over your network, following the recipe shown in this tutorial, but you could equally well set up Emby to stream it much more efficiently and through a convenient web interface. Or you could even use MPD (Music Player Daemon) to set your server up as a network-controlled music player. Just add large speakers, a powerful amplifier and several gigabytes of psytrance.