Linux file servers play an essential role. The ability to share files is a basic expectation with any modern operating system in the workplace. When using one of the popular Linux distributions, you have a few different file sharing options to choose from. Some of them are simple but not that secure. Others are highly secure, yet require some know-how to set up initially.
Once set up on a dedicated machine, you can utilize these file sharing technologies on a dedicated file server. This article will address these technologies and provide some guidance on choosing one option over another.
Samba Linux File Server
Samba is essentially a collection of tools to access networked SMB (Server Message Block) shares. The single biggest advantage to Samba as a file sharing technology is that it’s compatible with all popular operating systems, especially Windows. Setup correctly, Samba works flawlessly between Windows and Linux servers and clients.
An important thing to note about Samba is that it’s using the SMB protocol to make file sharing possible. SMB is a protocol native to Windows whereas Samba merely provides SMB support to Linux. So when considering a file sharing technology for your needs, keep this in mind.
Now those of you who are familiar with SMB and its colorful history may be wondering where a “dialect” of SMB called CIFS comes into play. In the most basic terms, CIFS replaces the older SMBFS. CIFS allows us to connect to and access a SMB2+ share without relying on a typical smb.conf file.
For example, I could set up my fstab to automatically mount a SMB share. Otherwise in order to access the same SMB share, I’d need to setup the appropriate conf file with the needed SMB details. More on this in a minute.
Samba is compatible with a wide range of conf file based configuration options. Some of these options are even integrated into distros and desktop environments. Other times, you need to edit the smb.conf file directly. Ubuntu and distros based on Ubuntu provide a GUI option for making a directory Samba ready/sharable. These GUI tools are useful for “guest” (non-registered user) accessible shares, however fail to provide users with the needed SMB user and password if one chooses to limit access to said share. Creating a SMB user still needs to be done from the command line. Thankfully however, the command needed itself is extremely easy to use.
Getting back to the previously mentioned smb.conf file, the most important elements of the conf structure look something like this:
[global] workgroup = workgroup server string = samba server security = USER encrypt passwords = yes smb passwd file = /etc/samba/smbpasswd guest ok = yes other global settings... [sharename] comment = comment path = path writeable = yes
Notice how the file is broken up into sections. Odds are that your own conf file will have more sections than this, but these are the core sections to be mindful of. The first section is known as the Global section. This references the details of the Samba/SMB server. Notice the Microsoft references like Workgroup? Each line must be filled in correctly to allow access to the target server. Remember the GUI for sharing files mentioned previously? This is made possible by utilizing the Guest line in the conf file. Keep in mind, if you want to use a username and password to protect your Samba share, you must create a SMB password for the assigned user. Then enter the appropriate user and password into the conf.
For example, if my current Ubuntu user is Pat and I wish to grant Samba access to that user on a SMB enabled Linux server, I’d need to create a unique SMB password for Pat on the Linux server itself. It’s the server playing gatekeeper here, so that’s where the SMB password must be created and stored.
So what is the best way to access a Samba/SMB share from a Linux client? Really depends on your needs. As mentioned previously, you can use fstab entries to create CIFS access to a share that mounts automatically. Personally, I think this makes the most sense for Guest shares since I’m not using SMB credentials in the fstab itself. The other approach is to simply browse to the share using smb:// in your file browser, then enter your assigned username (usually your existing client Linux user) and your SMB password when prompted.
Where do I recommend using Samba? I’ve found that Samba is best suited for work or home environments where files need to be shared among multiple operating systems. It’s important to note that Samba is to be used in a trusted local network environment. It’s not suitable for file sharing over the internet or in an environment whereas public users are able to access some shares but not others. Samba/SMB security is not really well suited for this type of situation.
NFS Linux File Server
NFS also known as the Network File System is a bit more complex than using Samba. Despite the learning curve, the benefits of using NFS are rock solid. NFS tends to perform faster, with less CPU operation than Samba. This isn’t to suggest that this is always the case, but overall NFS is the sought out file system of choice for Linux file servers.
Like Samba, you have a specific file in which you assign your shares. These shares are known in NFS terms as exports. What’s interesting about a NFS share is how it’s access configuration is based on single line entries instead of section based entries. For a very (possibly over-simplified) example:
/directory1 *(ro,sync,no_root_squash)
/directory2workstation(rw,sync,no_root_squash)
The star (*) is a wildcard indicating that any client with any hostname can access that specific share. For added security, you can define a case sensitive hostname of the client. Next we have ro and rw. These letters represent read only and read/write. With Directory number one above, this might be a directory we are granting the wildcard client access to, so we’d rather not allows anyone on the network have write to directory share capability. The second directory, does allow a single hostname client to read and write to the share. Both directory shares do not allow root access however. You might look at the wildcard (*) hostname as being similar to providing Guest access.
Once you’ve configured your exports (shares), you’re ready to mount those exports. Unlike Samba, NFS is conf file and command line only. So you create your configuration, then you either manually mount the export from the command like or you can use fstab to make the mounting process automatic at boot.
In my experience, I’ve found NFS to be outstanding for rich media sharing, large file transfers and general reliability.
Linux File Server Additional Considerations
With both examples above, you need to make sure the needed files (or kernel modules) are installed. You need to make sure any related services are running. And of course when something doesn’t work, it’s almost always a basic configuration issue. Just double check your configuration and compare it to the documentation provided for the file sharing solution you decide to go with.
As to which storage type you decide to use, that really comes down to storage strategy. Do you need redundancy, are you looking for access speed, or perhaps you also wish to incorporate remote offsite access using technologies like SSH with sFTP?
With regard to the former, that’s something you’ll need to determine based on your specific needs. As to whether to allow sFTP access to a share, consider this. File sharing is done at the kernel level. So you shouldn’t have any concerns about file corruption. That said, if you use NFS and SSH/sFTP on the same share, you can pass along the “lock” option. I’d argue that if you’re really concerned about versioning or other related issues, use Nextcloud as it provides proper “versioning” and is a better option than a sFTP file server. There is no reason why you can’t share a Samba share or NFS export with Nextcloud.
What say you? Which file sharing technologies do you prefer when building a Linux file server? Hit the comments and tell me about it.
