How To Share folders with NFS

[Polaris96]

How to share folders with NFS
mark 1 mod 4

Changelog
This is where I tell everybody what I've done since mod3. You can skip this if it's your first time here.
1. Some formatting. Finally got around to adding some boldface and italics.
2. Some discussion given to sshfs v nfs tunneling for security. I now think it might be better to tunnel nfs and I explain why under "who nfs is not for" Watch for a "Howto set up sshfs" coming in mark 2 of this HowTo. I'll also explain HOW to tunnel nfs in mark 2
3. Mention is made (thank you very much, birdyWA) that nfs4 IS working in squeeze. Expect in depth coverage of nfs4 in mark2mod2 or mark2mod3. I'l need a bit of time to set up the squeeze experimental platform and break nfs4 enough times to feel confident giving a howto.



Who this tutorial is for:
Most anybody that wants to share files between *NIX machines by creating common directories. Also, anybody who wants a refresher on the basics of NFS3 and how to implement shares using CLI.

People who want a quick, easy, way to share folders behind a firewall or gateway.

People who are amenable to terminal code. It's ok if you're a novice. So long as you follow these directions, you definitely can make NFS work. There will be no treatment of GUI utilites here. I don't hate the GUI, I just don't know it. Somebody else will have to address that issue. You won't need the GUI to set up sane, robust, NFS shares. Read on, if you like.


Who this tutorial is not for:
People looking to network Windows platforms with *NIX platforms. NFS can be made to do this, but it's a pain and I will not touch the issue, here. You want Samba for that task.

People who need very tight security or people who want to share folders across a WAN. Again, NFS will play ball if you tunnel through ssh. That's not necessary if you use sshfs instead of NFS. These days, I actually think a tunnelled nfs share may be best for long term WAN connections. This is because nfs shares set up very much like normal filesystems. For instance, putting a permanent nfs share in fstab presents a sane and logical place to check out the parameters of your share as seen by the client machine. It sits in the stack with all of your other permanent mount filesystems.

sshfs doesn't work like that. Setting up an sshfs is REALLY REALLY quick and easy (it's so easy I couldn't believe I hadn't messed up the first time I did it). The caveat is that sshfs's don't set up "normally" - you can see them in mtab but you can't register them in fstab. I don't like losing the sanity of having everything in front of my nose with fstab. So, as of now, I'm advocating sshfs for any temporary connections, secure or otherwise (you can't believe how quick it sets up!). For permanent I'd rather set up a normal nfs share and tunnel it through sshfs. In case you think I'm teasing and leaving you all in the dark about both sshfs setup and HOW to tunnel your nfs shares, I'm not. I will soon be posting instructions on how to do both of those operations. bear with me.

As an aside, NFS4 will accept kerberos security, but it's not currently working in lenny. I have good info that it works in squeeze. When I have worked all of that out, I'll add a section to this howto.


So, What is NFS?
NFS, or Network File System, is an internet protocol that allows sharing of data between a client and server machine. The shared directory looks and acts like a local device to the client machine. The lines above are paraphrased from the manpage.

Basically, you will generate a directory in one machine called the server. This will be shared over some network connection with another machine called the client. The client machine will think it has a “normal” directory even though it will be talking to a drive on a totally different machine. It will look, act, taste, and smell like any the other folders on the client machine.

So, if Bob has a directory called, “Photos” that he's sharing with Sue, she will also see a directory marked “Photos”. Either one of them can look at the photos or add photos (if you give them access, that is). The users don't care if they are on the client or server. The directory will behave the same way to either user.


What do we need to get started?
Let's start with two *NIX machines. Use two Linux machines. Better yet, two Debian machines (just for now. That way we won't have ANY compatibility issues for our training session). I don't know if NFS works with Apple, but I bet it does. I am not teaching you to connect windows machines via nfs so no windows, please.

You also need a physical network. Any kind will do. Please set it up and work out any physical bugs before we go further. There are other tutorials to help you set up a basic network. You should be able to ping your machines from one another. If you're using IPTABLES as a local firewall, be sure to disable it. If you don't understand what I just said about IPTABLES, you don't need to worry about it.

We want a solid, functioning network to start with, so that we can be sure that any problems come from NFS and not some other process.


Time to start:
Before we begin, we need to pick our server. If you already have a server machine, it's a no-brainer. If you have not designated a particular machine to be your server, you can use either one. I recommend using the “better” of the two platforms as the server (ie. faster and/or bigger storage).

Got a server? Good. Fire it up.

You need to install some software from the repository to your server machine. SO! Pour a cup of coffee, open your terminal, and let's get started

Code: Select all

Code:

~/$su
~/#apt-get install nfs-common  (you probably already have this, but type it, anyway)
~/#apt-get install nfs-kernel-server

Next, we'll modify the /etc/hosts file. This file is like a phonebook for your network. You don't NEED to do this, but if you don't, you'll need to set up your share based on IP addresses. I like names better. They make it easier to understand what you're looking at.

For editing config files, I use a terminal program called nano. You don't have to use it if you don't want to. If you use a GUI app, make sure you are opening it as root or you will not be allowed to save your changes.

Code: Select all

Code:

~/#nano /etc/hosts

You're going to see something like this:

Code: Select all

127.0.0.1	localhost
127.0.1.1	Aimee.Polaris	Aimee

12.13.14.15	kiki.Polaris	kiki
5.5.5.100	Penelope.Polaris	Penelope
5.5.5.100	Lara.Polaris		Lara




# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

Yours might not have anything between “localhost” and the gobbledygook about Ipv6. That's ok because we're going to add it. What you need to do is go over to your CLIENT machine, open a terminal, and Code:

Code: Select all

~/$su
~/#apt-get nfs-common	(again, you probably have it already.  It won't hurt to make sure.)
 ~/#ifconfig eth0

and you'll see something like this:

Code: Select all

eth0      Link encap:Ethernet  HWaddr 00:1a:da:15:60:e5  
          inet addr:5.5.5.105  Bcast:5.3.4.255  Mask:255.255.255.0
          inet6 addr: fe80::21a:70ff:fe15:6078/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:42369 errors:0 dropped:0 overruns:0 frame:0
          TX packets:28219 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:49232950 (46.9 MiB)  TX bytes:3357769 (3.2 MiB)
          Interrupt:16 Base address:0xcc00 

Notice the text “inet addr” on line 2? That's the stuff you care about. Add that number as a line below the localhost on the SERVER machine. Then hit the tab key and type the host name for the client. You can use anything you like as long as your consistent, but you should use your machine's proper name:

If all of this is new to you, consider the following model to help you understand hosts and domains:
User@host.domain . So, I could be polaris96@Aimee.Polaris . If you typed that address as a destination in the Polaris internal email system, I would get the message. See, you've been looking at this stuff for years. Now you know how to say it in Geek.

Back to the task at hand:

Code: Select all

127.0.0.1	localhost
127.0.1.1	Penelope.Polaris	        Penelope

5.5.5.105	Maeve.Polaris		Maeve

OK, I've added the client to the server as “Maeve in the domain Polaris” You don't need the domain, but I recommend using one. There are some functions which work easier when addressed to an entire domain. We won't talk any more about it here. You can think of each machines as a Host and the entire network as a Domain or Workgroup.

Make sure to save your changes on the server machine. In nano, you do this by pressing [ctrl-o]. Now that we have addressed the client, we can use the name “Maeve” to designate that Host (machine). Close out of /etc/hosts. If you're using nano, this is done by pressing [ctrl-x]

Next we'll allow the client to call us. We do that by editing the /etc/hosts.allow file So Code:

Code: Select all

~/# nano /etc/hosts.allow

it will look like this:

Code: Select all

# /etc/hosts.allow: list of hosts that are allowed to access the system.
#                   See the manual pages hosts_access(5) and hosts_options(5).
#
# Example:    ALL: LOCAL @some_netgroup
#             ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
#
# If you're going to protect the portmapper use the name "portmap" for the
# daemon name. Remember that you can only use the keyword "ALL" and IP
# addresses (NOT host or domain names) for the portmapper, as well as for
# rpc.mountd (the NFS mount daemon). See portmap(8) and rpc.mountd(8)
# for further information.
#

The function that hooks up nfs shares is called mountd. It's like mount but for network shares. We need to make sure it will take calls from Maeve, so we add the following line (just type it into the white space anywhere under the commenets):

Code: Select all

mountd: Maeve

If we wanted to share across the enitre network, we could instead say:

Code: Select all

mountd: .Polaris

Which is how my file actually reads. That's one reason for declaring a domain in your hosts file. Save the changes and exit from the file.

DO NOT FORGET THIS STEP. IF YOU DO, YOUR CLIENT MACHINE WILL “SEE” THE SHARE, BUT YOU WILL NOT BE ABLE TO MOUNT IT.


As an interesting sidenote, I noticed when reviewing this article that /etc/hosts.allow actually says you can't use host or domain names with rpc.mountd (the full name for mountd). Don't worry about it. The directions I'm giving come directly from a long functioning file service. I think it's probably vestigial - once upon a time you couldn't do it, but these days you can. If it still worries you, look at the manpage for mountd. It actually recommends adding host or domain names when referencing mountd in hosts.allow. You get used to this kind of thing. It's one of the quirks of our home built distro they'll sort it out, someday.


Next, we need to make a directory on the server that will be shared. You can put it anywhere you want to. I like to place mine in /home at the same level that users get a folder. We do it like this:

Code: Select all

~/#cd /home
~/home#mkdir shared

Good to go, except that the directory “shared” is owned by root. That's bad because we want regular users to share the directory and root's property is usually write protected. We can make it available to everybody like this:

Code: Select all

~/home#chmod ugo+rwx shared

Now, we have allowed everybody to do anything with the directory. You might want something more restrictive for your particular purposes, but use this for now. There's a great permissions tutorial on the board if somebody needs help, there.

Next, we need to tell the NFS server to export the directory to our client. We do this using the /etc/exports file:

Code: Select all

~/home#cd /etc
~/etc#nano exports

Here's what mine looks like:

Code: Select all

# /etc/exports: the access control list for filesystems which may be exported
#		to NFS clients.  See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes       hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes  gss/krb5i(rw,sync,no_subtree_check)
#

/media/jukebox	jenny(rw,sync,no_subtree_check) Aimee(rw,sync,no_subtree_check)
/home/Admin	 jenny(rw,sync,no_subtree_check) Aimee(rw,sync,no_root_squash,no_subtree_check)

Yours will be blank beneath the comment lines. Let's look at how we enter the shares.

First, you enter the path to the server directory that will be shared. Then, after a space (I use a tab) you enter a list of the hosts that are allowed to “see” it with a space between each client. For me, the clients are jenny and Aimee. You can put different export options inside parentheses following each hostname.

Make sure that you never leave spaces between the export options. Your syntax should follow this model:

Code: Select all

hostname(option1,option2,option3)

If you leave any spaces, exportfs will think you're describing another machine to recieve the directory. This gives headaches.

In our case, /etc exports might look like this:

Code: Select all

/home/shared 		Maeve(rw,async,no_subtree_check)

What's inside the parentheses? That's a good question. The 'rw' says the client can read and write in the share. We could put 'ro' for read only, if we wanted. Then, only the server could write to the directory.

The 'async' has to do with how data is exchanged. Asynchronous is faster but synchronous is (very slightly) more robust. I use sync as nothing but force of habit. Either one is ok.

'no_subtree_check' is the default behaviour. You can leave it out. If you don't add it, you get annoying messages on the command line when you export the share. That's why I put it in.

Notice in my /etc/exports file where it says 'no_root_squash'. NFS normally kills any root access from a client machine. THAT IS SMART. 'no_root_squash' will allow admin level access in the server share from the client.

This is dangerous. Don't do it unless you know what you're all about. I don't actually have it enabled on my network. I stuck it in because, once in a while, you need a sledgehammer. USE WITH CAUTION.


After we save and exit from /etc/exports, we have one last thing to do:

Code: Select all

~/etc#exportfs -ra

That command offers the shares to our designated client machines. On the client machines, if you're running a GUI, you'll see a pop-up as if you had plugged in a usb drive. If you allow it to automount, you can explore the directory from the client's desktop. Congratulations! You now have a file server. Isn't that cool?

At this point, you can use the nfs share. Everything that follows fits into the category of “polishing the system”


Permanent mounting
Sometimes, you want a share to hook up as soon as you power on. Here's a good way to do that. First, I like to make a directory on the client with the same path as the one I'll be attaching from the server.

In our case, this will be /home/shared. I'm not going over how to make it, again. Look back to the server setup if you need precise directions.

After we have set up a client directory as our “normal mountpoint,” we need to add a line to /etc/fstab, like this (Make sure you are working on the CLIENT):

Code: Select all

~/#nano /etc/fstab

mine looks like this:

Code: Select all

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        			0       0
/dev/md1        /               reiserfs defaults       		0       1
/dev/sda9       /boot           ext2    defaults        		0       2
/dev/VG_0/LV_0  /home           xfs       defaults      		0       2
/dev/sda7       none            swap        sw              		0       0
#dvd drives
/dev/scd0        /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/scd1       /media/cdrom1   udf,iso9660 user,noauto     	0       0
#NFS drives
Penelope:/media/jukebox	/media/jukebox	nfs	defaults		0	0
Penelope:/home/Admin	/home/Admin		nfs	noauto			0	0

The only lines you care about are the two under the comment #NFS Drives. You need to add something similar. Notice the syntax:

servername:[path on the server] [path on Client] nfs defaults 0 0

Obviously, the server and client paths come from your own network.

'nfs' is the fstype DO NOT USE NFS4 if you're running lenny. Exportfs and mount support it, but I'm pretty sure mountd DOES NOT. I will update this HOW TO when that changes.

'defaults' should be fine for almost everybody. 'noauto' means do not automatically mount the fs at startup.

You can put some descriptive data in fstab with a 'noauto' option to allow an “easier” manual mount. For instance, I can type:

Code: Select all

~/#mount /home/Admin   

to mount that share, instead of having to type:

Code: Select all

~/#mount -t nfs Penelope:/home/Admin /home/Admin

The two trailing zeros have to do with failure modes and fsck checks. Don't worry about them. Just type the zeros.

And there it is. You now have the tools to set up basic file service.


Common Problems during initial setup / configuration
/etc/hosts.allow – BY FAR the most frequent issue is that you forgot to allow access to mountd. If you can “see” the share on the client, but not mount it (even as root). This is your issue.

Incorrect access levels. Check that the server directory is accessible to the client for mounting. You may need some chmod work to get it right. Also, remember that the Client directory must have correclty set permissions, too. If you don't need security, make it all 'chmod ugo+rwx [filename]'

Syntax errors in your files. All of the work in this How-To came right off my network (some names and canonicals were changed to protect the guilty lol), so it should be good as reference. READ THE MANPAGES I like to do this:

Code: Select all

~/$man exports > export.man 

Which prints a textfile that I can spool out from openoffice or Kate. Manpages are your bestfriends for CLI stuff.


Where next?
NFS is not very secure. The skills you learned here will make it fairly easy to implement the sshfs if you want high security.

If you like working on the server machine from the client, learn how to use ssh. It's very easy to get terminal access with ssh, but make sure to put the server's address into the client's /etc/hosts file. You know how, now. If you like remote terminal, I ask that you stay away from the telnet command. Telnet is an unsecure nightmare. Stick with ssh

You might also want to learn how to set up an internal mail server. Sendmail is another security nightmare, but I recommend it as a first step because it's easy. Set it up, play with it, then REMOVE IT and use postfix for any real emailing.


In Conclusion
Everything I have spoken about here is LOW TECH by modern standards. The good news is that it works great and makes a small footprint for big utility. Be careful to stay INSIDE the firewall or gateway when you're setting up this kind of system. I hope this will whet your appetite for using the terminal – it's like granpa's Nash pickup, archaic, but still useful and built like brick outhouse.


Good Reference
Manpages, Debian online documentation, How-Tos on this forum, and, of course, other users. Please try to find the answer to your problem in the available documents before starting a thread. I also have no problem answering questions about this material posted on this thread, but I travel a lot on business. Bear with me if I don't get to you right away.

Code: Select all

[thewanderer]

A great howto, covering all possible pitfalls and solutions. I'd just suggest adding some structure to it - headings and formatting are a good thing for the reader.
As for NFS itself, I use it at home to export user directories from a central server. However, I have to keep UIDs and GIDs in sync, so passwd and group files are shared by all my systems. As it is not possible to just load those files from NFS after booting the system, I boot over NFS and my PC's are in fact diskless, yet full-featured workstations (regular middle-end and high-end hardware). Various tutorials are scattered around the Web, describing netboot in detail - many of those are Debian specific.
However, I am currently moving towards a complete migration to a disk-based setup and discovered that managing identities over the network is a major pain in GNU/Linux and on other Unices. This is possibly the only thing Microsoft got right - hassle-free Active Directory is the way to go, until there is some real, manageable user directory and authentication service for Linux. For now, I don't see myself implementing Kerberos and LDAP and struggling to keep them in sync, adding entries for various daemons and users, and installing hacks to get me tickets - they expire, and need typing in commands from the Linux console. I know how it's functioning in my school (I'm with the staff), and it's a nightmare to keep it up and running.
I was thinking of going for PAM-MySQL and I am actually convinced that, in current situation, it's the best solution which can be integrated easily (thanks to PAM/NSS).
The only thing that keeps me forced to use Kerberos is the secure authentication in NFS. Too bad there aren't any real management tools and I can't use adduser to handle things for me.

[Polaris96]

Excellent point regarding user and group ids.

There are a few ways to handle this. My favorite way has always been to make the initial NFS share an admin directory with no_root_squash. Then, from the client machine, I use a few simple scripts to carry over any required users and groups from a master file on the server. Best of all, If you need a couple of accounts on many different machines, you can work through ssh and script the entire procedure to run from the server, itself (you call the server from the client via the server) After it's all set up, you remove no_root_squash and you're good to go.

I may, in the future, include the scripts and a "HowTo" for doing this. For now, though, I'm targeting more mundane "home office / mediacenter" stuff. So far as headings and formatting go, all are there. I may at some point change the heading font to boldface. Until I've covered everything I want to hit in content, I'm waiting on formatting.

The good news for any novices reading this reply is that you don't need to worry too much about it. The golden rule of NFS at home is "don't make things unnecessarily secure or unnecessarily complicated." That's why it's essential to work in a secure environment - behind a gateway or firewall. If you keep your permissions easy, all the stuff about UIDs and GIDs is much less important. Here's what you Need to Know:
1. if you set up the share as:

Code: Select all

~/$su
~/#mkdir share
~/#chmod ugo+rwx share

Anybody can enter, read or write to the share. This is best for multimedia apps like pictures, movies, or songs
2. if you set up the share as:

Code: Select all

~/$su
~/#mkdir share
~/#chmod ug+rwx share
~/#chmod o+rx share

Anybody can enter or read from the share, but only the owner and people in the owner's group can write to it. This kind of situation is where the stuff that was mentioned above comes into play. If you're going to use UNIX user and group security, you must make sure that the Group, and/or User IDs that "own" the share are exactly the same on the client as they are on the server. I will be revisiting this when I have time.

[merlyn]

Hi Polaris96, I'd just like to thank you for providing a great how to.

The steps were well explained and in a logical progression, making the set up simple and straightforward.

I've set up plenty of SAMBA servers in the past, both as a file server and PDC, & I don't need to tell you how awkward that can be at times.

However, as my home network is exclusively Linux now, and primarily Debian, it seemed the logical choice.

I look forward to further installments.

Cheers.

[Polaris96]

Thanks, merlyn. I'm looking to launch mark 2 this week. The best addition, to my mind, will be a changelog at the top of the article so you guys can see any new stuff I've added. I've also been experimenting with ways to avoid and repair the "stale nfs file handle" error condition, which can really be a pain. Hope your setup went smooth and look for mark 2 posting by wednesday. b/r Polaris

[chadmichael]

Nice post. I have some questions about the hosts.allow and hosts.deny system.

1) Do these things apply to all network access on a machine? In other words, can I also use these things to "firewall" SSH or FTP?
2) If these files are both empty, that works too, right? Because access is allowed by default, correct?

[chadmichael]

I'm having some trouble. After I do the exportfs -ra, I don't see anything on my other machines? THe output from the exportfs -ra doesn't indicate any problems though.

[thewanderer]

As far as I know, programs have to be hosts_access-aware to use this feature. Currently portmap, rpc and tcpwrappers support it (inetd? don't know - removed it ages ago). I'm not aware of other services, but you should be able to check that in the manpages/documentation easily. If a daemon refers to /etc/hosts.{allow,deny}, then it does support host-based access control.
However, note that this is what we have iptables for nowadays. And, besides address/host-based security, authentication mechanisms (and preferably other means like physical link-layer security) should always be in place if you are aiming for an actually secure setup.

2. To clarify, an extract from hosts_access manpage:

Code: Select all

ACCESS CONTROL FILES
       The access control software consults two files. The search stops at the first match:

       ·      Access will be granted when a (daemon,client) pair matches an entry in the /etc/hosts.allow file.

       ·      Otherwise, access will be denied when a (daemon,client) pair matches an entry in the /etc/hosts.deny file.

       ·      Otherwise, access will be granted.

       A non-existing access control file is treated as if it were an empty file. Thus, access control can be turned off by providing no access control files.

Thus, no access policy defined means no restrictions.

------

What do you mean by 'can not see'? Please elaborate.

[chadmichael]

The tutorial says that I will see an automatic mount icon appear. I don't see that. I also tried the network browsing tools and couldn't see the shared folder. That's how I find SMB shares, maybe it's different in the case of NFS. I also looked in /mnt and a couple of other random locations.

[thewanderer]

Anyway, you should be able to mount NFS with mount command. I don't really know why it is not detected by the graphical tools, there could be a plenty of reasons. Here, it works flawlessly under KDE.
I've got all my shares in /etc/fstab. Have you added your filesystems there?
I really doubt that NFS has a mDNS announcement function built-in. Automatically discovering NFS hosts on a network takes more than in the case of Samba. If you need that feature very badly, look at avahi-daemon...

[chadmichael]

If you can “see” the share on the client, but not mount it (even as root). This is your issue.

How would you "see it" ?

[thewanderer]

You would "see" it in a sense that remote host's rpcd and portmap respond, showing ports on which nfs service is running, and exposing NFS shares.
chadmichael: try

Code: Select all

mount -t nfs hostname:/path/to/my/nfs /local/mount/point

to mount a certain share at a local mountpoint.

[chadmichael]

Code: Select all

mount -t nfs hostname:/path/to/my/nfs /local/mount/point

This works for me, but I can't get it to auto mount from my entry in fstab.

Here's my fstab entry

machinetwo:/home/storage /home/storage nfs defaults 0 0

And here's the manual line that succeeds:

sudo mount -t nfs machinetwo:/home/storage /home/storage

What could be the difference?

[Polaris96]

@chadmichael

Sorry I couldn't reply sooner.

1. IRT hosts.[allow deny], You can use them as a sledgehammer to restrict services, hosts, and domains if you want. The default setting for these files is "allow," as you surmised. I can't give a whole tutorial on how to set these up elegantly, though. It would take too long. As has been mentioned, iptables is good general security system and I would learn iptables cold before I started worrying about nifty tweaks in hosts. I mostly use hosts to block LAN peers and only because it keeps my LAN rules in their own separate file from my web rules in Iptables. Check out the hosts_access manpage for more info on hosts.[allow deny]

I might revisit this topic once I have the nfs tutorial completed. Like I mentioned in the main tutorial, the problem with talking security is that it's like talking politics - somebody is bound to disagree with how you do things. I know people who won't even share opinions b/c they're worried about someone guessing at their strategy. Oh well... My own systems use both iptables and hosts.* Each method has benefits and drawbacks and they can work well together if you're careful.

2. So far as not seeing shares goes, I may remove that advice from the tutorial. I DO see the share, but at this point I'm not sure what's generating that data. Reviewing the manpages and browsing /var and /proc has only shown reference to available mounts on the server. The gist of what I'm reading says, "makes shares available for the client," not, "offers a share to the client."

For all of that, my system is recognizing the shares under kde as they become available. I think, somehow, kde is polling the server for available connections. I have NO IDEA what service controls this but I bet hald is involved (Hardware Abstraction Layer). I can't frontburner this, right now, but I will be looking into it and will post here when I figure it out.

The files you'll be interested in on the server are:

Code: Select all

/var/lib/nfs/etab  #shows available mounts and allowed hosts
/var/lib/nfs/rmtab  #shows shares that are actually mounted
var/lib/xtab  #nfs and mountd manpages refer heavily to this but it's empty on my servers

on the Client, you have the vanilla:

Code: Select all

/etc/mtab  #shows currently mounted filesystems
/proc/mounts  #shows the same thing but it's more legit - you're looking up the kernel's skirt with /proc.
 

For the moment I'm advising that exportfs makes the share available and mount gets it, but you need to know it's there, already. SOMETHING on my box (intermittently - I hate that word) is polling and discovering my shares, but it isn't nfsd and I really don't know what it is at this time.


3. fstab issues. My first statement must be the obvious - is your server booted and ready to go before you try to reboot the client? Assuming the answer to that is "yes," it may be that the system isn't ready for an nfs share when init mounts fstab. Try changing the option from "defaults" to "noauto" Then reboot., become root and code:

Code: Select all

mount [dirpath]  #where dirpath is the destination directory (if fstab is working right it will grab the fstype
and source from fstab and mount properly. 

If that works normally, you may not have all of the nfs modules set to load at bootup. Let me know if this is the case and we'll go into more detail. Otherwise, we'll have to try something else to get you in business.

[ComputerBob]

I followed this step-by-step pretty well, and overall, I think it's very good, though I agree that some more headers (or clearly numbered steps) would make it easier to follow, especially ones that make it clear which steps you do on the server and which steps you do on the client. Right now, that detailed information is sort of buried in a lot of explanatory verbage, which makes it hard to find the details when you're looking back and forth between your server's screen and this step-by-step which is displayed on a different computer.

Unfortunately, even though I tried to follow every step very slowly and carefully, when I finished, my client Debian PC (Squeeze with KDE 3.5.10) did not "pop-up" any notification that my server Debian PC (Lenny with KDE 3.5.10) had something to serve. And I was not able to mount my server's new share on my client, either manually or by adding an entry to fstab. I kept getting error messages that the share didn't exist.

So I started over and followed every step all over again.

But that just confirmed to me that I had done all of the steps correctly the first time.

And when I finished, my client still couldn't "see" my server's share.

Then, just out of curiosity, I tried mounting my server's share in my client's fstab, using the server's IP ADDRESS, instead of its NAME, and as soon as I saved fstab, KDE popped up a dialog box, asking me what to do with the new storage device.

When I rebooted my client, its new IP-addressed fstab line FOUND my server's share, and from then on, I was able to access that share from the client without any problems.

That makes me wonder if either I'm missing something, or your step-by-step instructions should include adding the SERVER's IP address and name to the CLIENT's /etc/hosts file, so that when people add the name of the server to the client's /etc/fstab, the client will be able to find the server.

[Polaris96]

Hey Bob, Thanks for the advice and the review. Haven't seen you around in awhile + happy new year

It sounds to me like your server isn't properly logged in /etc/hosts on the client machine. Check for a syntax error even if you think it's good. IP reachable/hostname unreachable is almost always an issue with etc/hosts.

So far as the "kde not noticing the shares" pathology goes, I have noticed this to happen intermittently on all of my machines. I still don't really know why. Check the postings above for some inferences I've made in this matter.

Always try to manually mount the share before you write it off. Lots of times the share is there but kde doesn't pick it up. I keep meaning to examine this behaviour but never seem to have the time.

I'll try to provide some better cookbook directions. I was hoping to give a theoretical basis as well as a "checklist" how to, but your suggestions are appreciated and I'm sure I can find a way to tighten up the verbage.

All the best.

[ComputerBob]

(unintentional double-post)

[ComputerBob]

Hey Bob, Thanks for the advice and the review. Haven't seen you around in awhile + happy new year

Thanks, and Happy New Year to you, too!

I still come by here at least 3 or 4 times every day, to see what others are posting, but I don't post as much as I used to.

To clarify, should my server PC be listed in my client PC's /etc/hosts file? Because my client's /etc/hosts file currently only contains lines that apply to my client itself, which would (I think) explain why I still have to use my server's IP address in my client's /etc/fstab in order to make my client mount my server's NFS share.

If my client's /etc/hosts file IS supposed to have a line that identifies my server's name and IP address, then was that line supposed to be generated automatically somehow, or does it always require someone to manually type it into the client's /etc/hosts file? I'm guessing that someone has to manually type it, but I don't think I've seen anyone mention doing that ON THE CLIENT in any of the tutorials that I've seen.

The bad news is that when I finally got my client to mount my server's NFS share (using my server's IP address in my client's /etc/fstab, my client would ONLY do it if I MANUALLY mounted the share after my client was all booted up -- my client refused to automatically mount the NFS share automatically during boot, no matter which fstab switch I used to mount the NFS share (hard, soft, _netdev, etc., etc.)

And my logs didn't show any error messages to help me figure out the problem.

The good news is that I finally figured it out, and my client now mounts my server's NFS share during boot EVERY SINGLE TIME.

The bad news is that it took me 13.5 hours to finally figure out what was causing the problem.

Yup, 13.5 hours.

The reason it took so long was because I kept Googling for answers and trying everything over and over and over and over, setting up my NFS over and over again, to try to figure out why it wasn't set up correctly.

But what I finally figured out was that my NFS had been set up correctly the whole time!

It turned out that the whole reason my client couldn't automatically mount my server's NFS share during boot was because my client had a misconfiguration in /etc/network/interfaces that kept its networking from being up and running in time for NFS to be able to "see" my server. And that misconfiguration was caused back when I first set up my client by using rsync to copy my server's entire / partition onto my client.

Of course, when I did that copying, I corrected all of the paths in my client's /etc/fstab and /boot/grub/menu.lst before I booted it up.

But I had forgotten that my server has 2 ethernet ports: eth0 and eth1. I only use its eth1 port.

In contrast, my client only has 1 ethernet port: eth0.

So back wnen I had copied my server's / partition onto my client, my server's copied /etc/network/interfaces started telling my client that it had 2 ethernet ports, and that it should use eth1 (just like my server does).

And every time my client booted up, it read /etc/network/interfaces and then tried to configure eth1 (which it doesn't have), before it would finally give up and figure out that eth0 was available, and then it would configure eth0.

But in the meantime, NFS had already tried to connect to my server, but it couldn't, because eth0 wasn't up and running yet.

Which forced me to MANUALLY mount the NFS share after my client was up and running each time.

BUT, after I edited my client's /etc/network/interfaces so that it contained only eth0, my client was able to configure and start eth0 right away during boot, and was then able to mount my server's NFS share automatically during every boot up.

I use my NFS server PC as my main PC, and now my wife can use my NFS client PC as her main PC. Both PCs are running Debian Squeeze (Testing) — but with KDE 3.5.10 and grub-legacy instead of KDE 4 and grub2 — and both PCs save all of our email, browser settings and user-created data onto my NFS server’s hard drive, which is also backed up to a separate hard drive.

Who needs knowledge and experience when you have patience, persistence and lots of time?

[Polaris96]

Glad to hear everything's up and running now. Don't feel too bad. The first time I set up NFS on a LINUX system (After lots of time in BSD and system V), it took at least 8 hours to figure out that mountd needed to be itemized in hosts.allow. These headaches are the very best teachers, regrettably.

So far as /etc/hosts goes: Yes, The client machine must have the server's hostname and IP address recorded in /etc/hosts. That's where mountd (or anything elses) looks first for name resolution. It's a pretty good practice to keep a "generic" /etc/hosts file on hand that addresses all of the domain names in your system. You can then rubber stamp the same file into each of your pcs and be confident that you can always reach out to the machines on you LAN by name.

Security weenies occasionally whine that providing hostnames can compromise security. Not Much. I wouldn't worry about it at all on a home LAN.

Hope this helps.

[ComputerBob]

That's what I suspected, though, like I said, I'd never seen any tutorial state that you need to edit the CLIENT's /etc/hosts file along with the server's. Thanks for your help!

I added debian1's name and IP address to debian2's /etc/hosts file. Then I edited debian2's /etc/fstab to change debian1's IP address to its name.

Ad NFS is still working.

It's kind of like magic.