# NFS RPC: Timed Out

## ColeSlaw

After doing an emerge -e system, my NFS doesn't seem to work.  Every time I try to mount a file system on my client machine, this is what I get:

```
tiax ~ # mount /mnt/pictures

mount: RPC: Timed out

mount: backgrounding "192.168.1.102:/mnt/backup/pictures"
```

The output of /var/log/messages on my server machine is this:

```
Mar  3 09:50:01 janjansen cron[13102]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )

Mar  3 09:50:05 janjansen rpc.mountd: authenticated mount request from 192.168.1.169:615 for /mnt/archive/video (/mnt/archive/video)

Mar  3 09:50:10 janjansen rpc.mountd: authenticated mount request from 192.168.1.103:986 for /usr/portage (/usr/portage)

Mar  3 09:50:15 janjansen rpc.mountd: authenticated mount request from 192.168.1.169:612 for /mnt/archive/video (/mnt/archive/video)

Mar  3 09:50:20 janjansen rpc.mountd: authenticated mount request from 192.168.1.103:745 for /mnt/backup/pictures (/mnt/backup/pictures)

Mar  3 09:50:25 janjansen rpc.mountd: authenticated mount request from 192.168.1.169:797 for /mnt/backup/pictures (/mnt/backup/pictures)

Mar  3 09:50:30 janjansen rpc.mountd: authenticated mount request from 192.168.1.169:616 for /mnt/archive/video (/mnt/archive/video)

Mar  3 09:50:35 janjansen rpc.mountd: authenticated mount request from 192.168.1.103:745 for /mnt/backup/pictures (/mnt/backup/pictures)

Mar  3 09:50:40 janjansen rpc.mountd: authenticated mount request from 192.168.1.169:919 for /mnt/backup/pictures (/mnt/backup/pictures)

Mar  3 09:50:45 janjansen rpc.mountd: authenticated mount request from 192.168.1.169:618 for /mnt/archive/video (/mnt/archive/video)
```

I have NFS version 3 server and client built into the kernel on the server machine.  I have NFS version 3 client built into the client machines.  All the machines have nfs-utils version 1.0.6-r6 installed.  They're all x

my /etc/exports:

```
# /etc/exports: NFS file systems being exported.  See exports(5).

#Shared Portage

/usr/portage            192.168.1.0/255.255.255.0(async,subtree_check,no_root_squash,rw)

#file server stuff

/mnt/backup/music       192.168.1.0/255.255.255.0(async,no_subtree_check,rw)

/mnt/archive/video      192.168.1.0/255.255.255.0(async,no_subtree_check,rw)

/mnt/backup/games       192.168.1.0/255.255.255.0(async,no_subtree_check,rw)

/mnt/backup/pictures    192.168.1.0/255.255.255.0(async,no_subtree_check,rw)

/mnt/archive/DVD        192.168.1.0/255.255.255.0(async,no_subtree_check,rw)

/mnt/archive/GAME_ISOs  192.168.1.0/255.255.255.0(async,no_subtree_check,rw)
```

I don't have IP Tables installed on any of these machines.  They're all behind my router's firewall.  Any suggestions?  Any other information that I could post that would be helpful?

Thanks for taking the time to look at this for me!

----------

## KShots

Are you running portmap? Did you start nfsmount?

----------

## ColeSlaw

Yep, both Portmap and nfsmount are running.

----------

## Edweirdo

I have the same problem.  I had been running my servers for years without a problem but a recent update caused this to start happening.  Sometimes the directories will mount and then they will just stop working (timeing out).

----------

## ColeSlaw

I have the same problem.  Very rarely, they will actually mount, but seem to disconnect after a while.  Anybody else out there know anything?

----------

## Janne Pikkarainen

I'll add a "me too" here. Something is clearly borked somewhere and it's "nice" to here I'm not the only one having issues with this one. Time to dig deeper...

----------

## Edweirdo

I think this bug is what we are experiencing (or at least what I am experiencing).

https://bugs.gentoo.org/show_bug.cgi?id=168170

----------

## KShots

Hmm... I'm guessing this would be on the server side of nfs. I'm using nfs-utils 1.0.10 on a diskless gentoo system with no problems, but the server is a FreeBSD box, not a gentoo box.

----------

## guillon

I have the same problem on three servers:

1. AMD64 - 2.6.16-gentoo-r9 - net-fs/nfs-utils-1.0.12

2. x86 - 2.6.19-gentoo-r5 - net-fs/nfs-utils-1.0.10

3. AMD64 - 2.6.12-gentoo-r6 - net-fs/nfs-utils-1.0.6-r6

So I think it's not a kernel, nfs-utils or architecture problem.

All of them run as servers of thin-clients networks (LTSP) on one interface and are connected to internet with another interface.

I've found that when the internet interface is down, mounts work fine. Then you can bring internet up and the terminals work ok.

----------

## jakommo

Hi all,

I got the same Problem, did anyone solved it?

I installed Arch Linux today on the same machine, to see if its a gentoo or a liunx problem, but it's no problem to mount the nfs share from Arch.

What I detected is that it also tells me several times " mountd[5700]: authenticated mount request from 10.2.2.1:919 for /home (/home)" in the Arch syslog messages but it mount anyway with no problems. The other thing I recognized is that if I ssh to my machine when booted gentoo it takes more than 8 seconds till I get the prompt for the password. If I boot up Arch and ssh to it it takes less than a second.

Mounting nfs from gentoo results in an RPC Timeout, nearly every time. I think I can mount it once in 10 tries.

I've tried upgrading and downgrading for kernel, nfs-utils, portmap (only upgrade, because there is no version to downgrade to), but it always gives me the same result: RPC Timeout.

please help me, I wanna stick with gentoo, because I like it very much and I'm used to from my old filesserver, my laptop and from the machines at work.

I'm running amd64 stable

regard 

jakommo

----------

## ColeSlaw

I never did solve this problem.  I became so frustrated dealing with it, that I just started sharing files with Samba (which doesn't work well, but at least it works).

If anybody else out there even has an idea what the culprit might be, I would like to know too.

----------

## jakommo

Hi ColeSlaw,

it's so frustrating there has to be a solution.

I setup Arch for now but I saved my gentoo partiton so I can go back to gentoo if there is a solution (hopefully).

btw: Do you experience the same "delays", as I described, when you ssh to your box? are you running x86 or amd64?

The strange thing is I've installed an new server some weeks ago (also amd64) at work and there was no problem. The server shares the / and the /home for more than 50 Diskless Clients and its working great. Ok it has an Core2Duo and a Hardware raid, mine is a AMD X2 4400 and software raid, but this can't be the problem.

jakommo

----------

## ColeSlaw

Now that you mention it, with that particular box, I do have delays when logging into ssh, and they are probably about 8 seconds.  I never thought much of it before.

I've always kind of thought the problem wasn't with NFS, but I'm not sure what to blame.  There may be a solution out here on the forums, but the most frustrating part is that I don't even have an idea what to search for.

----------

## KShots

The delays in ssh could be caused by a reverse lookup taking place. Not sure what the settings are to disable this... but you may be able to do a simple (temporary) fix by putting the client's IP and a hostname under /etc/hosts on the server. The proper way would be to set up a DNS server somewhere, which knows about your whole network to prevent this sort of thing on every machine.

As far as NFS goes... Try mounting with the tcp option (mount -o tcp, or add it to your options list in fstab). If this succeeds, you may be dealing with a noisy network (ie, because NFS relies on UDP packets normally - which are not guaranteed to arrive - you may be dropping packets). TCP would guarantee that every packet gets where it's supposed to go (by re-transmitting if necessary). This adds a small amount of overhead to the traffic, but you gain guaranteed delivery.

If this is the case, check your wiring - if you made any custom cables, verify that you twisted the right pairs (I accidentally twisted the wrong pairs in my network once and suffered similar problems).

----------

## jakommo

 *KShots wrote:*   

> The delays in ssh could be caused by a reverse lookup taking place. Not sure what the settings are to disable this... but you may be able to do a simple (temporary) fix by putting the client's IP and a hostname under /etc/hosts on the server. The proper way would be to set up a DNS server somewhere, which knows about your whole network to prevent this sort of thing on every machine.
> 
> .

 

THANKS for your quick response, you saved my day and my gentoo installation.

I've tried that and it helped for the ssh delay. It also nearly solved my nfs problem. I can mount nfs now and its working 9 out of 10 times.

the strange thing is sometimes it mounts in less than a second and most of the time  it takes about 10-20 seconds. BUT it mounts.

I've increased the export time outs in /etc/conf.d/nfs and now it should work.

Thanks again

Jakob

----------

## jakommo

OK THANKS again,

I've configured bind for my network today, and now ssh and nfs work with out any problems or delay.

jakob

----------

## SuperDindon

Still no happy ending for me.

It doesn't even mount from the server.

I don't understand, everything works apart from files transfers. ssh has no delay but scp hangs ( "stalled" ). I've tried a looooot of things, that's awefully frustrating, please someone save me !..

----------

## SuperDindon

This is getting me sick..

----------

## SuperDindon

AAAAAAHHHHHHHHHHHHHHHHHH... getting closer, FINALLY......

Once I try mounting the NFS volume rpc.mountd eats 100% CPU, and doesn't stop when I stop trying.

----------

## jakommo

 *SuperDindon wrote:*   

> Still no happy ending for me.
> 
> It doesn't even mount from the server.
> 
> I don't understand, everything works apart from files transfers. ssh has no delay but scp hangs ( "stalled" ). I've tried a looooot of things, that's awefully frustrating, please someone save me !..

 

Maybe a hardware problem?

Did you try booting a liveCD an scp from/to it?

what about samba, same problem there?

----------

## CyberFoxx

I'm having the same problems, but my situation is a tiny bit different. Right now, all my filesystems are ReiserFS. I've been thinking about changing over to JFS, just do to less overall overhead. (I don't really need all the extreme verboseness that ReiserFS provides.) Right now exporting these ResierFS filesystems via NFS works perfectly. But when I converted the filesystems to JFS, and tried to mount from a client, rpc.mountd uses 100% CPU and pretty much goes out to lunch. Converting the filesystem back to ReiserFS actually fixes the problem. I have even tried using ext3, with the same rpc.mountd "lockup" problem.

One comp is using gentoo-sources-2.6.21-r3 and the other is using gentoo-sources-2.6.21-r4. I have even tried downgrading nfs-utils from 1.1.0 down to 1.0.12 on the server, still no change.

This is quite annoying, because I really want to change from using ReiserFS.

----------

## CyberFoxx

Well, upgraded both comps to gentoo-sources-2.6.22, and still getting the problem. If I try to export a filesystem that uses either JFS or ext3, rpc.mountd on the server just starts using 100% CPU and hangs on mount requests from the client, and the client reports back "NFS RPC: Timed Out." But if I use ReiserFS, everything's fine. Honestly, how can filesystem choice affect this?

----------

