Boy, it has been a long time since I haven't been able to find my answer using Google, but, sadly, my Google-fu skills are weak on this matter.

I have two computers. One is basically acting as a server and the other is my media center PC. Both are running Slackware 14, and the server is 64bit (with multilib, although, I don't think it matters) and the mediacenter is 32bit. Server is hardwired to a gigabit ethernet router, and the mediacenter is connected to the router via wireless N at 150Mbps (link quality 100/100, signal level 75/100, noise level 0/100 according to iwconfig).

I have 5 NFS shares exported on the server, and I have those 5 shares mounted at boot time via the fstab on the mediacenter. Now the weird part. One, only one, of the shares will eventually time out and create a stale nfs handle. I can lazily umount it and remount it right back, but within the next day or so, it will be a stale nfs mount again. On both computers, no errors are thrown out to the dmesg.

Now for my /etc/exports from the server:

And now for my /etc/fstab from the mediacenter:

It is always the /share/music mount that goes bad. I try to start playing music with xbmc, and then it always errors out, so I then have to go umount -l that share and then remount it and it will work fine. But I never have issues with any of the other shares. I am really baffled by this.

NOTE: the options used in exports are ones I found online. NFS was still pretty new to me at the time and most of the reading of the man page went kinda over my head. If there are better options to be used for streaming media, I'm more than willing to try them out (TV will mix between SD and 720p, while movies can go up to 1080p, music is typically 256kbps or less).

I used to use Samba, but that proved inadequate for any HD streaming over wifi and quite often had issues with SD content.

I don't know what causes the dropouts but here are my NFS mmount options:

NFS_OPTIONS="defaults,noatime,tcp,hard,intr,bg,timeo=5,rsize=32768,wsize=32768,nfsvers=3"

Mostly I use the following in my /etc/exports:

ro,no_root_squash,sync,anonuid=99,anongid=99,subtree_check,no_wdelay

Just a small home network.

1 members found this post helpful.

Thanks, Woodsman. You always seem to come through when I need help. I'll have to give those options a try. Is there any particular reason you use the options you do, or was it like me and you just got them from a website and have just continued to use them?

And is there any specific place I specify NFS_OPTIONS so it can be used in the fstab, or do I manually put those options for each entry? I only ask this because I like my fstab formatted cleanly, and having all those options thrown in there might mess a bit with my OCD

Does the directory from which music is exported have the most deeply-nested structure (i.e. the most subdirectories)? I suspect it is and I think that is why it times out. Specifying tcp over udp, as Woodsman has done in his fstab may help you then.
Also, if the exports are ro, then using async in /etc/exports may help with that as well. (async with rw is not recommended)

1 members found this post helpful.

A little of both. I will never pretend to be a network guru. At the time I created those options there were reasons, yes, but I now have forgotten. I remember spending much time reading man pages and forum discussions and tinkering with different settings. There was no magic or cleverness involved --- I bludgeoned my way through until I found settings that worked for me.

The rsize/wsize numbers came from reading about improving throughout on gigabit systems. I have five physical machines here and two are gigabit systems. I wanted to take advantage of those speeds as best as possible.

The nfsvers parameter came from an LQ post.

My apologies for that. I use those options in two different places. One is directly in my fstab to create a "noauto,users" mount to my HTPC videos partition:

htpc:/var/videos /var/videos nfs defaults,noatime,noauto,users,tcp,hard,intr,bg,timeo=5,rsize=32768,wsize=32768,nfsvers=3 0 0

I then use kwikdisk at other systems to allow users to view the mount. I use noauto in fstab because the HTPC is not always on. At the HTPC the videos partition is in /etc/exports as ro and the entire partition is root:root anyway, in order to help me avoid typical "fat thumb" and "brain fart" episodes.

The other place I use those options is in a special data container file I store at /etc/default/network. This file is my own creation. I use that file to store various common variables I source in my shell scripts. I have a couple of shell scripts I use to connect to other systems in my home network. I source those parameters as a variable in those scripts. That is where the mysterious "NFS_OPTIONS" declaration derives.

I use one more parameter to help with my gigabit connections. I never performed any meaningful tests. I found the suggestion online a few years ago. I have the following in my rc.local:

Another thing I do is ensure the port mapper and nfsd use the same ports all the time:

http://www.slackwiki.com/NFS_and_Firewall

I can't offer insight into your particular problem. My experience is when NFS works everything is smooth as silk but when not then NFS is a PITA. NFS also is not graceful about losing a server connection. KDE is worse in that when NFS loses a connection KDE will grind to a halt. I think because of all the kio slaves. With that said, as you are using the files in read-only mode, perhaps give fskmh's suggestion a try and use async. Sync mode is useful for write operations but probably not important for read operations.

As a side note, I would test a different app with the music files. I use xbmc too but I don't use that app to play my music files. I use Amarok. I also don't stream my music files as I have copies of them on my HTPC. Still, testing with a different app might help produce some clues or at least confirm the problem is network related.

Some nominal things to check are file permissions and hosts file. Make sure all music files are 644 and directories 755. Make sure all music files are owned by an appropriate user:group. Make sure all local systems are properly defined in /etc/hosts to ensure NFS has no problems with DNS resolving.

Another idea is to ensure sufficient nfsd processes. The default in the rc.nfsd script is 8. I never had a problem with that number on my home network but who knows.

Lastly, don't forget the obvious. Perhaps something on the music server is causing the disconnects. I've done things like that, beat my head looking for clues, and then discovered I had a cron job or something similar calling a script that caused my headaches. For example, just yesterday I decided to look into a small quirk I had noticed for a long, long time with my backups. With each backup I always noticed a set of files being rsynced that I knew were not being used and hence, should not be changing. I discovered a script I run at logout from /usr/local/bin was touching a group of files and there was no reason for me to do that. Of course, I am the one who wrote the script but the idea here is sometimes we do subtle things and don't notice for days, weeks, or even months.

1 members found this post helpful.

I just checked, and I have as much as 14 directories nested in /share/music, and I have 10 nested in /share/movies (which doesn't have the problem, but it was the next closest). I'll definitely have to try changing it to tcp.

But, I am using these shares in an rw mode. xbmc will download album art (and for the movies and tv shows, it will download dvd covers, posters, fan art, subtitles, and more). Putting these shares in a ro mode, I feel, would hurt my experience with xbmc. So if it can be avoided, I'd like to keep it rw.

@Woodsman, wow... thanks for the extremely in-depth post. I will have to tinker around with various options and do some digging through man pages. Right now, I am only running gigabit from the server to the router and then wireless to the htpc, but I do plan on eventually getting an ethernet connection to my htpc, but I haven't wanted to breakout my sheetrock saw just yet. So, I will definitely keep your gigabit stuff in the back of my mind when I do get everything up and running.

And I kinda figured you couldn't specify a variable from within the fstab, but in case I was mistaken, I wanted to ask. But with using a separate app, I guess I could, but then I would need to minimize xbmc and break out my keyboard and possibly the mouse to be able to utilize it. I like using xbmc because I can just control everything with my remote control and the keyboard and mouse can stay tucked away in the cabinet. But utilizing a separate app wouldn't prevent the nfs mount from going stale. When the share is working properly, xbmc has no issues playing the files.

As for your last bit with something locally causing it, I don't think that is the case. From Slack13 on, I've tried to just reconfigure my machines using only references to previous settings. I ran into issues with my 12.2 upgrade because of carrying over scripts that were of no use on the system, but I didn't bother to check before I started using them. I don't think I have any of my own scripts running on this machine (the htpc is a different story, but the hdmi audio has proved to be a pain with stock Slack14, but I am pretty sure it is just the one, and it only runs after X has started up to redo the audio levels, since alsactl can't remember the previous volumes I stored).

So, I might've lied with this. Turns out I have only shared the music directory that is sorted, and not my whole music disk. So, it is only a folder depth of 3 (the main music folder, then artist, then album). So, all my other mounted shares have substantially more nested directories than this one. But I did remount it with the newer options, so we'll see if it wants to become stale again after a few days.

Well, I am still not sure why only one share would go bad, but when I switched to a wired network, the problem went away (and xbmc runs soooo much better on gigabit). I guess I'll just chalk it up to my shoddy wireless connection. I did try many of Woodsman's suggestion options after thoroughly reading through the man page, and I was still experiencing dropouts on wireless.

May I suggest that you consider using autofs. This way the NFS drives are mounted only when needed, and then released a minute or so after use. I've set this up at a few places - and the neat thing is that your "links" survive reboots - because they're technically not mounted.