Hack60.Share Files Across Platforms Using Samba

Hack 60. Share Files Across Platforms Using Samba

Linux, Windows, and Mac OS X all speak SMB/CIFS, which makes Samba a one-stop shop for all of their resource-sharing needs.

It used to be that if you wanted to share resources in a mixed-platform environment, you needed NFS for your Unix machines, AppleTalk for your Mac crowd, and Samba or a Windows file and print server to handle the Windows users. Nowadays, all three platforms can mount file shares and use printing and other resources through SMB/CIFS, and Samba can serve them all.

Samba can be configured in a seemingly endless number of ways. It can share just files, or printer and application resources as well. You can authenticate users for some or all of the services using local files, an LDAP directory, or a Windows domain server. This makes Samba an extremely powerful, flexible tool in the fight to standardize on a single daemon to serve all of the hosts in your network.

At this point, you may be wondering why you would ever need to use Samba with a Linux client, since Linux clients can just use NFS. Well, that's true, but whether that's what you really want to do is another question. Some sites have users in engineering or development environments who maintain their own laptops and workstations. These folks have the local root password on their Linux machines. One mistyped NFS export line, or a chink in the armor of your NFS daemon's security, and you could be inadvertently allowing remote, untrusted users free rein on the shares they can access. Samba can be a great solution in cases like this, because it allows you to grant those users access to what they need without sacrificing the security of your environment.

This is possible because Samba can be (and generally is, in my experience) configured to ask for a username and password before allowing a user to mount anything. Whichever user supplies the username and password to perform the mount operation is the user whose permissions are enforced on the server. Thus, if a user becomes root on his local machine it needn't concern you, because local root access is trumped by the credentials of the user who performed the mount.

6.6.1. Setting Up Simple Samba Shares

Technically, the Samba service consists of two daemons, smbd and nmbd. The smbd daemon is the one that handles the SMB file- and print-sharing protocol. When a client requests a shared directory from the server, it's talking to smbd. The nmbd daemon is in charge of answering NetBIOS over IP name service requests. When a Windows client broadcasts to browse Windows shares on the network, nmbd replies to those broadcasts.

The configuration file for the Samba service is /etc/samba/smb.conf on both Debian and Red Hat systems. If you have a tool called swat installed, you can use it to help you generate a working configuration without ever opening vijust uncomment the swat line in /etc/inetd.conf on Debian systems, or edit /etc/xinetd.d/swat on Red Hat and other systems, changing the disable key's value to no. Once that's done, restart your inetd or xinetd service, and you should be able to get to swat's graphical interface by pointing a browser at http://localhost:901.

Many servers are installed without swat, though, and for those systems editing the configuration file works just fine. Let's go over the config file for a simple setup that gives access to file and printer shares to authenticated users. The file is broken down into sections. The first section, which is always called [global], is the section that tells Samba what its "personality" should be on the network. There are a myriad of possibilities here, since Samba can act as a primary or backup domain controller in a Windows domain, can use various printing subsystem interfaces and various authentication backends, and can provide various different services to clients.

Let's take a look at a simple [global] section:

 [global]    workgroup = PVT    server string = apollo    hosts allow = 192.168.42. 127.0.0.    printcap name = CUPS    load printers = yes    printing = CUPS    logfile = /var/log/samba/log.smbd    max log size = 50    security = user    smb passwd file = /etc/samba/smbpasswd    socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192    interfaces = eth0    wins support = yes    dns proxy = no 

Much of this is self-explanatory. This excerpt is taken from a working configuration on a private SOHO network, which is evidenced by the hosts allow values. This option can take values in many different formats, and it uses the same syntax as the /etc/hosts.allow and /etc/hosts.deny files (see hosts_access(8) and "Allow or Deny Access by IP Address" [Hack #64]). Here, it allows access from the local host and any host whose IP address matches the pattern 192.168.42.*. Note that a netmask is not given or assumedit's a pure regex match on the IP address of the connecting host. Note also that this setting can be removed from the [global] section and placed in each subsection. If it exists in the [global] section, however, it will supersede any settings in other areas of the configuration file.

In this configuration, I've opted to use CUPS as the printing mechanism. There's a CUPS server on the local machine where the Samba server lives, so Samba users will be able to see all the printers that CUPS knows about when they browse the PVT workgroup, and use them (more on this in a minute).

The server string setting determines the server name users will see when the host shows up in a Network Neighborhood listing, or in other SMB network browsing software. I generally set this to the actual hostname of the server if it's practical, so that if users need to manually request something from the Samba server, they don't try to ask to mount files from my Linux Samba server by trying to address it as "Samba Server."

The other important setting here is security. If you're happy with using the /etc/samba/smbpasswd file for authentication, this setting is fine. There are many other ways to configure authentication, however, so you should definitely read the fine (and copious) Samba documentation to see how it can be integrated with just about any authentication backend. Samba includes native support for LDAP and PAM authentication. There are PAM modules available to sync Unix and Samba passwords, as well as to authenticate to remote SMB servers.

We're starting with a simple password file in our configuration. Included with the Samba package is a tool called mksmbpasswd.sh, which will add users to the password file en masse so you don't have to do it by hand. However, it cannot migrate Unix passwords to the file, because the cryptographic algorithm is a one-way hash and the Windows hash sent to Samba by the clients doesn't match.

To change the Samba password for a user, run the following command on the server:

 # smbpasswd  username  

This will prompt you for the new password, and then ask you to confirm it by typing it again. If a user ran the command, she'd be prompted for her current Samba password first. If you want to manually add a user to the password file, you can use the -a flag, like this:

 # smbpasswd -a  username  

This will also prompt for the password that should be assigned to the user.

Now that we have users, let's see what they have access to by looking at the sections for each share. In our configuration, users can access their home directories, all printers available through the local CUPS server, and a public share for users to dabble in. Let's look at the home directory configuration first:

 [homes]    comment = Home Directories    browseable = no    writable = yes 

The [homes] section, like the [global] section, is recognized by the server as a "special" section. Without any more settings than these few minimal ones, Samba will, by default, take the username given during a client connection and look it up in the local password file. If it exists, and the correct password has been provided, Samba clones the [homes] section on the fly, creating a new share named after the user. Since we didn't use a path setting, the actual directory that gets served up is the home directory of the user, as supplied by the local Linux system. However, since we've set browseable = no, users will only be able to see their own home directories in the list of available shares, rather than those of every other user on the system.

Here's the printer share section:

 [printers]    comment = All Printers    path = /var/spool/samba    browseable = yes    public = yes    guest ok = yes    writable = no    printable = yes    use client driver = yes 

This section is also a "special" section, which works much like the [homes] special section. It clones the section to create a share for the printer being requested by the user, with the settings specified here. We've made printers browseable, so that users know which printers are available. This configuration will let any authenticated user view and print to any printer known to Samba.

Finally, here's our public space, which anyone can read or write to:

 [tmp]        comment = Temporary file space    path = /tmp    read only = no    public = yes 

This space will show up in a browse listing as "tmp on Apollo," and it is accessible in read/write mode by anyone authenticated to the server. This is useful in our situation, since users cannot mount and read from each other's home directories. This space can be mounted by anyone, so it provides a way for users to easily exchange files without, say, gumming up your email server.

Once your smb.conf file is in place, start up your smb service and give it a quick test. You can do this by logging into a Linux client host and using a command like this one:

 $ smbmount  '//apollo/jonesy'  ~/foo/ -o username= jonesy, workgroup=PVT  

This command will mount my home directory on Apollo to ~/foo/ on the local machine. I've passed along my username and the workgroup name, and the command will prompt for my password and happily perform the mount. If it doesn't, check your logfiles for clues as to what went wrong.

You can also log in to a Windows client, and see if your new Samba server shows up in your Network Neighborhood (or My Network Places under Windows XP).

If things don't go well, another command you can try is smbclient. Run the following command as a normal user:

 $ smbclient -L apollo 

On my test machine, the output looks like this:

 Domain=[APOLLO] OS=[Unix] Server=[Samba 3.0.14a-2] Sharename    Type   Comment ---------    ----     ------- tmp  Disk   Temporary file space IPC$  IPC   IPC Service (Samba Server) ADMIN$  IPC   IPC Service (Samba Server) MP780  Printer  MP780 hp4m  Printer  HP LaserJet 4m jonesy  Disk   Home Directories Domain=[APOLLO] OS=[Unix] Server=[Samba 3.0.14a-2] Server  Comment ---------  ------- Workgroup  Master ---------  ------- PVT  APOLLO 

This list shows the services available to me from the Samba server, and I can also use it to confirm that I'm using the correct workgroup name.