Yeah, I hear you talking but I don’t believe a word. “You say you’re gonna keep it simple.” “You say you’re gonna stick to just having one Linux machine to play around with and you’re not gonna need to think too much about networking.” Well, let me tell you that it just doesn’t work that way at all.
You see, there is one dirty little secret that long time Linux users know but keep to themselves. Something no one tells newbies. But I will. So here it is: Linux is highly addictive, and having one Linux machine is like eating just one potato chip. You can’t do it, I tell you! Second-hand computers are cheap and Linux is a free download, so there’s nothing stopping you from finding yourself with a house full of happy Linux boxes, all humming away. There’s always another reason to add one more machine… Just wait, you’ll see.
Another dirty little secret they won’t tell you is that Samba, the almost universally accepted software used to interface Linux with Windows style peer to peer networks, is a complex program. That it’s hard to configure and is a source of frustration for even the most advanced Linux user at times. Yes, there are GUI based tools that promise a point and click setup of Samba shared folders, but they always disappoint in the end. To make things worse, the average home user will find a dizzying array of setup options and configuration schemes when they look on-line for guidance. I struggled with Samba for a long time until I ran into a very simple solution that makes working with it a breeze. This article and video will show you how to setup a client/server style network that will work whether you have 2 machines or 200.
Getting the server software is as easy as installing the samba package from your distro’s repositories. Once it’s installed, the hard part is getting it configured to do your bidding. If we want to have a trouble free networking experience, it’ll take a bit of thought and we need to set some goals.
Goal One: Keep it simple
I once took a job at a large radio and TV facility with several studios and offices. Needless to say, there were a lot of computers; some were for general office work and others were highly specialized production and automation machines. The production network was well designed, all going by the guidelines set by the company that provided the automation software. No worries for me there. However, the office network was a mess. Basically, every desk had a PC and every PC was set up to share files and printers in a Workgroup. Making it so everyone could share everything. There were lots of machines on the network with lots of folders shared on each one. There was no way to know where anything was so you’d have to call the person you wanted to share something with and have them click where you told them to find it. It was a mess and something had to be done. The solution was super simple and I have setup every network the same way since.
I grabbed one of the extra PC’s collecting dust in the storage room and stripped it down to be a lean, mean serving machine. All this thing did was sit in the corner and share files, as it added bonus it needed very little attention. This machine shared one folder only. Each person in the building had a folder within that folder and everyone had access to everything. Instead of each workstation sharing a folder, they just had a shortcut on their desktop to the server. Anyone who wanted to share files could simply drag them into their own corresponding folder, or drop the file in someone else’s folder on the server. By doing so, anyone on the network could access them. Files on the server could be added, deleted or modified in place. Everyone knew that what they put on the server was public and that they needed to keep local copies of stuff they didn’t want to lose, just in case something got blown off the server or it crashed. With a memo and a meeting to explain how it worked the office network was suddenly much more efficient and people finally knew where to look for the files, they wanted to share. I was a star and everybody loved me.
Most home users won’t want to set aside a separate machine just to serve files. Luckily, it’s no big deal because a simple Samba server can run in the background on whatever machine you choose. Preferably one that is online the most. You can also share things like music and video folders in such a way that anyone can read or copy the files, but they can’t delete them or change them. You don’t even have to be logged into the account you setup for the server or shared files from; those files will be available on the network as long as that machine is up and running. Someone else can even be using their own account on it too. The Samba server doesn’t care.
One of the really nice things about networking this way is that only one machine has to be configured as a server. Pretty much every Linux distro comes with a Samba client setup already and all you have to do is browse the network from a file manager to connect to any machine serving files. You could even setup multiple machines if you so desired.
Goal Two: Keep it real
Do you have a bunch of wireless devices that need to be hooked up to the Internet? Do you have more than one computer that needs Internet access? Most likely, the answer is yes and you probably do all that with a router. That router probably acts as a hardware firewall and the only way for anyone to get to your devices would be for them to get into your local network. Which is fine, so long as you have a strong Wi-Fi password and don’t give it out to everyone that passes by. If your password is secure, then you can feel relatively safe when it comes to local network shares. That said, there’s really no need to make users log into a shared folder just to play a song or copy a picture that you yourself have designated as shareable. Many of the pitfalls we encounter with Samba have to do with security features, so why not just turn them off?
Another major issue with Samba, even when sharing with Windows computers, is file permissions. By default, Samba tries to preserve file permissions. The standard Samba setup will mean that files you pull off of the network will have to be copied to a local folder to make them belong to you or manually edited to change permissions, by using root privileges in most cases. This is a pain and could be really confusing for less savvy users on your network. What most home users want is to just be able to copy a file onto a local machine and have it be theirs. . . so that’s what we’ll do.
A Word About Windows
Samba was designed to share files between Windows and Linux and it works quite well most of the time. Setting up a Windows machine to work with Samba is not something I’m prepared to get into, but it is worth noting that Windows 7 and up presents some challenges. Microsoft came up with a new network protocol called Homegroup that is totally incompatible with Samba. You’ll have to configure your Windows machine to use standard Workgroup style enterprise network protocol just to interact with Samba. There’s lots of info available on how to do this and it’s not too terribly hard to get going.
A curious quirk of sharing files with Windows is that sometimes a Linux file name won’t work with Windows. The naming conventions are just slightly different. Windows doesn’t care about the case of the text when dealing with files and Linux does. Also, there are some characters that Linux will gladly let you use in a file name that Windows won’t. Samba tries to reconcile these issues with mixed results. You may find yourself having to rename a file every once in a while to get it through the Samba network, even when going from one Linux machine to another Linux machine. One of the ways to get around these bugaboos is to take any files that absolutely must retain the exact same properties and throw them into a tar.gz file before putting them on the network. This is a good thing to keep in mind when using Samba to share configurations files. that you want to import into another machine.
https://www.youtube.com/watch?v=n-uSzkGhHDY
The Configuration Process
The goals we talked about above will be achieved by creating custom configuration files from scratch. I go through how to install the Samba server and create your own custom Samba configuration files step by step in he video, but here are some sample files to show you what needs to be in them. Use this as a quick reference when you’re configuring your own network:
Contents of /etc/samba/smb.conf
[global]
server string = Dell Desktop
workgroup = WORKGROUP
security = user
map to guest = Bad User
name resolve order = bcast hosts wins
include = /etc/samba/smbshared.conf
Contents of /etc/samba/smbshared.conf
[Joe's Music]
force user = joe
path = /home/joe/Music
writable = no
public = yes
[Network File Server]
force user = joe
path = /home/joe/Public
writable = yes
public = yes
You can change the share names and the name of the Workgroup, of course. It’s all in the video.
One Last Thing…
You may get a message asking whether you want Samba to automatically configure itself when you install an updated version of the Samba server. Don’t! Just say not to make sure your custom config files aren’t overwritten. It’s a good idea to keep a backup copy of your configs, as well. I keep a document file with the text I always share and cut and paste when I need to re-install Samba after a change of distro or an upgrade to the OS on the machine running the server. It takes two minutes at the most and then I’m back in business.
Good luck and don’t have too much fun playing with Linux file sharing!
Related Posts:
Joe is a fan of Ubuntu Linux and Open Source software and recently started offering Ubuntu installation and support for those just starting out with Linux through EzeeLinux.com. The goal of EzeeLinux is to make Linux easy and start them on the right foot so they can have the best experience possible.
Joe lives in historic Portsmouth, VA in a hundred year old house with three cats, three kids and a network of computers built from scrounged parts, all happily running Linux.