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:
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
|
