Section 7.6. My Files Are on That Other Computer

7.6. My Files Are on That Other Computer

What's the point of a network if you can't share files? Linux provides several different protocols for file sharing. Two of the most common are the Network File System (NFS) and Samba.

NFS is the most efficient way to share directories between Linux and Unix computers. Unfortunately, if you have connection problems, shared NFS directories can hang up a client computer.

Samba supports sharing between Linux/Unix and Microsoft Windows computers. It's almost up-to-date with the latest developments in the Server Message Block/Common Internet File System (SMB/CIFS) protocols. While you can configure a Samba server as a Primary Domain Controller (PDC) or as a member server of an Active Directory (AD) network, Samba cannot yet act as a Domain Controller on an AD network.

The process of configuring NFS and Samba shares is a complex topic; a complete discussion is beyond the scope of this book. We assume in this section that you know the basics of installing and activating the appropriate NFS and Samba packages on your system. For more information, see Managing NFS and NIS by Hal Stern and Using Samba by Jay Ts et al. (both published by O'Reilly).

The annoyances that we'll deal with are:

• Configuring NFS directories risks hangs when the network is down.

• Connecting to shared Samba directories normally requires root account access.

7.6.1. Connecting with NFS

The process of configuring a regular NFS share is elementary for the Linux geek. However, if you want to minimize the risk of hangs when a client tries to mount an NFS directory, you'll need to follow these instructions carefully.

Under NFS, the system on which a shared directory physically resides permits other systems to mount the directory by listing it in /etc/exports. Access can be further limited with the /etc/hosts.allow and /etc/hosts.deny files. Given the NFS security issues, such as no provision for encryption over the network, root access is prohibited by default.

It's common to configure a shared directory good for all users, such as /home, from a central server. For example, you might see the following line in /etc/exports:

 /home    192.168.0.0/24(rw,sync) 

This line exports the directory /home to all systems on an internal Class C network, allowing read/write access and making the application that writes a file wait until the data is stored on the remote disk.

On the client side, there are two basic ways to mount a shared NFS directory: with a hard mount or a soft mount. A hard mount is more resistant to dropped connections, which can corrupt your data. In contrast, a soft mount can keep your system from hanging if there's a network problem when your system attempts to connect to a NFS directory. So if you need reliability when writing to a shared NFS directory, consider a hard mount. If you have trouble connecting to NFS server systems, consider a soft mount.

Default mounts through NFS are hard mounts. So if you choose a hard mount, you can configure it with a line such as this one in the client computer's /etc/fstab:

 192.168.0.10:/home    /server     nfs    nfsvers=2    0   0 

The /home directory on 192.168.0.10 will be hard-mounted on /server. To use a soft mount, configure it explicitly on the client:

 192.168.0.10:/home    /server     nfs    soft,nfsvers=2    0   0 

Naturally, this isn't the only way you can configure a mount from a client. You can mount the remote /home directory on the local /home directory. You can also use the fully qualified domain name of the NFS server, as long as forward and reverse DNS pointers are available for that server.

There is one more way to mount a shared NFS directory: the automounter, which we'll describe at the end of this annoyance.

7.6.2. Connecting with Samba

One of the annoying things about Samba is that you have to be the root user to connect to a shared Samba or Microsoft directoryat least under the defaults for some distributions. Regular users need to connect to shared directories all the time. I'll show you some ways around this problem in this section.

To support access, users need an account on the Samba server or on the corresponding PDC. Just as you can configure a single database of Linux/Unix usernames and passwords on a NIS or LDAP server, you can configure a single database of Microsoft usernames and passwords on a Domain Controller. You can configure a Microsoft Windows server or a Linux server configured with Samba as a PDC.

Let's start with the simplest solution to the user account problembut the solution that requires the most manual work for you. This solution is to configure a user account for every user to whom you want to give access to a share on your Linux system. This works fine in a small environment where only one server offers files or printers.

For example, I've configured my own account with the following command, which prompts for a password.

 smbpasswd -a michael 

If you're using a Samba 2.x system, the corresponding command is smbadduser.

To browse the shares from a Samba (or a Microsoft Windows) server, smbclient can help. For example, if you want to view the shares on a computer named sunshine, run the following command:

 smbclient -L sunshine 

If you're familiar with Microsoft operating systems, you may recognize the output. It's similar to what you see through the Network Neighborhood or My Network Places tools, or from a net view \\sunshine command.

Most of the latest Linux GUI desktop environments make it easy to browse a Samba/CIFS network. Current GNOME desktops support network browsing with Nautilus, while KDE desktops can access the network via Konqueror. Just enter the following in the address bar of one of these tools:

 smb:/// 

If you don't see the address bar in either browser, press Ctrl-L (Nautilus) or Ctrl-O (Konqueror). You can then enter smb:/// in the Location text box.

The standard Samba configuration file, smb.conf, supports access by regular users to their home directories. The following commands in the file serve up the home directory for each user:

 [homes]         comment = Home Directories         valid users = %S 

But therein lies a problem. Regular users aren't normally allowed to use the mount command. On many Linux distributions, they aren't even allowed to use the Samba mount commands such as smbmount.

Debian alleviates this problem by configuring two key commands as SUID root, supporting access by regular users: smbmnt and smbumount. If you're running Samba on another distribution, you can set SUID permissions with the following commands:

 chmod u+s /usr/bin/smbmnt chmod u+s /usr/bin/smbumount 

Non-root users can now use smbmount and smbumount to access their home directories on other Linux computers. The first command mentioned in the previous sentence is not a misprint; because smbmount uses the smbmnt command, regular users can work with either one, as long as they have set the noted SUID permissions.

It's possible that other distributions will adapt Debian's settings for smbmount and smbumount. At that point, user connections to remote home directories shared via Samba will be less of an annoyance.

As described shortly, you can use the automounter to mount shared Samba directories. However, unless the share is not password-protected, that means you'll have to add a password in clear text to an automounter configuration file.

Regular users now have access to their home directories. In this configuration, as user michael, I can access my home directories on other computers. For example, to mount the /home/michael directory on a directory named test/ on my SUSE laptop, I'd run the following command. Commands such as smbmount prompt for passwords as required (the password on the server or Microsoft Domain Controller, not the user's local system), so I'll need to enter the password that I created on the Samba server when prompted:

 smbmount //suse1/michael test 

Then I can unmount this share with the following command:

 smbumount test 

One user can also log in as a different user on the Samba server. Assuming Samba passwords have been assigned, I could log in to Donna's account with the following command:

 smbmount //suse1/donna test -o username=donna 

Once again, I'm prompted for Donna's password. I could add the password to the command line, but it would appear in clear text on the terminal, where a "shoulder surfer" (someone who looks over your shoulder for information) might read the password.

7.6.3. Automating Mounts with the Automounter

If your network is less than reliable, network mounts can cause trouble. Mount attempts to inaccessible NFS servers can even cause your computer to hang.

This is where the automounter can help. It is invoked by the kernel when someone accesses a remote directory in any waysuch as by issuing an ls command or opening a file in that directory in a text editorand performs the necessary mount over NFS or SMB/CIFS. The behavior is impressively fast and really makes networking seamless.

The automounter is available by default on most modern Linux systems. It requires the autofs service and is configured through the /etc/auto.master configuration file. In most cases, the file you configure is /etc/auto.misc. Most distributions include commented sample commands that you can use. We'll show simple examples here. For more information, see http://www.tldp.org/HOWTO/Automount.html.

7.6.3.1. NFS automouter share

In this example, I've set up an NFS share of the /home directory from the suse1 server. I've also configured the following command in my /etc/auto.misc file:

 linux     -rw,soft,intr      suse1:/home 

I can then access the NFS share as a regular user with the following command:

 ls /misc/linux 

7.6.3.2. Samba automouter share

In this example, I can use the standard Samba share of my /home/michael directory from the suse1 server. All I need is the following command in my /etc/auto.misc file:

 michael -fstype=smbfs,username=michael,password=michael ://suse1/michael 

I can then access the Samba share with the following command:

 ls /misc/michael 

Notice that configuring the automouter this way stores your password in clear text, which is a big security hazard because this file is readable by default by all users. If you choose to share Samba directories in this way, limit access to this configuration file to the root user:

 chown 600 /etc/auto.misc