NFS client share won't auto-remount when rebooting server
 

i have a debian box that backs up to partitions on a file server mounted with NFS. the problem is, every time the file server reboots, the NFS partitions don't remount on the client. access is then "permission denied," and i have to manually unmount the share and then remount it again.

i always thought that NFS remounted automatically, so i did some searching, and it appears that in fact it's supposed to, e.g., from o'reilly:

"One interesting thing about NFS is its statelessness. You can reboot a server and the client won't crash. It won't be able to access files on the server's export while the server is down, but once it returns, you'll pick up right where things left off. Other network file sharing systems are not so resilient."
http://www.onlamp.com/pub/a/bsd/2002...y_Daemons.html

i've looked through /var/log/messages and syslog, but i didn't see anything. in fstab, i have for ex.:

i wonder if it's the tcp option, as i seem to remember i added that awhile ago for some supposed advantages. it's just that i haven't rebooted in so long that i don't remember if that's when the problem started.

I wouldn't know, never having used the tcp option. However, I imagine it would be the cause of the problem. Normally, nfs uses UDP which doesn't require a persistent connection. TCP, in contrast, involves negotiating a persistent connection.

It's easy enough for you to test--just remove the tcp option and see if that fixes things. I imagine it will.

thanks very much for your reply, IsaccKuo. i took out the tcp option, umounted the partition, remounted it with the new settings, then rebooted the server, but unfortunately the NFS shares still didn't automount.

i then rebooted the client, and then after verifying that the shares were mounted, i rebooted the server again, and again they wouldn't automount.

root@moe:/home/jeff # ls -l /mnt/backup
ls: /mnt/backup: Permission denied

there aren't any new messages in messages or syslog since the client reboot. are there other logs i could check? i just don't get what's going on here. do i need to reexport the shares on the server even though the mount options on the client are what changed? that doesn't seem to make sense, but i'm really stumped. perhaps they really are mounted, only it's a permissions issue somehow, as indicated?


------------------------------------>
btw, just thought i would add that in general i agree with your point on the rudeness issue. i tend to approach it on a case-by-case basis, though, and it seemed clear (maybe i was wrong about that, but it seemed clear to me) that this was a case where the poster was just a kid who was impatient and frustrated, and was trying to get some attention, not a seriously rude slammer. i've seen a lot worse than him, at least, which is no excuse of course. but in context i thought he was worth a second chance, with the warning about his behavior and that he wouldn't get help if he kept it up (if you notice that i told him). again, respect your standing by principle, though. i will definitely be more stringent about that myself after considering the points you made on it.

If you're getting the error during the "ls" command, then it sounds like the share WAS mounted. You can use the following to determine what filesystems are mounted:

more /etc/mtab

This will tell you what filesystems are mounted without any permissions problems clouding the issue. It sounds like some weird permissions problem.

Hmm...do you have "no_root_squash" or subtree checking as options somewhere on the server? Depending on your exports, it's possible that a change in the default behavior of subtree checking might have a weird permissions effect.

i think (hoping) you might be right about the subtree issue. i added no_subtree_check at one point, perhaps that's doing it. i just checked with one volume exported with no_root_squash and the other one with root_squash, and it didn't make a difference, so now i'm going to check without the subtree check.

an interesting things is that checking cat /proc/fs/nfs/exports on the server after a reboot shows that nothing is exported. after i manually mount the shares again on the client, it shows they are, though:

so if it's not the no_subtree_check, maybe that's another clue to consider. thanks again, will update in a minute.

>>>>>>>>>>>>>>>>>>>>>

ARGGH! still doesn't work. now I'M getting frustrated. :scratch:

okay, cat /etc/mtab is showing the shares, but they are blocked to ls (even as root ??) by the permission denied.

nobody account on each machine has same UID, which is how i thought it needed to be.

the *actual* permissions are a bit complicated (to me, at least) because the shares are mounted partitions with their own permissions that one user needs to use, and the exported shares need a couple of different users, and the backup share is in turn a subdirectory of a mounted share (if that matters). everything used to work fine, so i don't know what happened, this seemed to start a couple months ago, i thought after i added some of the options (the tcp and no_subtree_check, etc.), but i guess not.

for now i removed all options but rw,sync but that didn't help. is there any easy way to troubleshoot permissions? would the way the partition is mounted locally on the server in the fstab affect how it is exported? everything is mounted with noatime and defaults, does it need something else (rw, etc.) for nfs??

I use tcp option all the time with mounting against NFS shares. That should not be a problem. Anyhow, no_root_squash is the option you need to set on the share you want to export on the NFS server. That way, the root user on the client can modify permissions and so forth. Make sure you got portmapper running on both machines as well.

Let us know how that goes for you.

-twantrd

i'm starting to think there must be a bug in the package of the distro (arch) that's running the nfsd apps. i have no_root_squash, rw on everything in sight, and i even changed the permissions on the locally mounted partition to 0777, as well as chowning it to root:backup, which is a new group i created just for testing this. i then added all my users to it, then added it to all the clients with the same GID and all users, and all the users also have the same UIDs on all machines. i stopped exporting all but the one partition (backup) for testing purposes. it still won't automount on server reboot.

so here's the breakdown, maybe someone can spot the error. if not, i'm going to have to conclude it's a bug and report it to the arch devs. i don't think it's a debian problem, because my laptop client is also arch along with the server and it won't remount on server reboot there, either. so it wouldn't make sense that it's debian, since the laptop has no association with the debian box.

SERVER - Arch Linux, current:
CLIENT - Debian, lenny:
i put in everything relevant i could think of, let me know if i left anything out that could be important.

I'm not familiar with troubleshooting rpcinfo or /etc/group; everything else looks perfect to me. I'd guess it's a bug also.

On one of your Debian machines, maybe you can set up a "dummy" test version of the backup directory...see if the "bug" occurs when Debian is the server also.

I use Debian 4.0 on all of my boxes, and NFS shares definitely survive server reboots. I know, because I've accidentally left a diskless workstation running while rebooting the server. It's spooky, having a diskless workstation survive temporarily yanking its OS partition away. During that time in limbo, the diskless workstation is one disc access away from a horrid crash.

great idea. i set up an NFS share on the debian box, and it worked perfectly. i rebooted debian, it remounted on the arch client, i rebooted the arch client, and it mounted perfectly. apparently something's wonky in the arch server package, is all i can conclude. i guess i'll alert them, see if anyone else there is having this problem. thanks for the help.