# HELP: Can't fix mount.nfs: Stale file handle error? [SOLVED]

## tld

Wow wow wow. I recall getting this years ago, but not in many years...though I don't ever recall it being this bad: I use an NFS mount between my mythtv frontend to a video directory on the backend system. Today I noticed it wasn't mounted...no idea why. Trying to mount I'm getting:

```
mount /mnt/remote_media

mount.nfs: Stale file handle
```

Even after rebooting BOTH machines. I've read more crap than I care to talk about on this and nothing's working. Any suggestion would be welcome.

TomLast edited by tld on Sat Sep 28, 2019 1:57 pm; edited 1 time in total

----------

## tld

I just tried from another machine and I get the same thing, so clearly it's something on the server. Wow...horrible.

Tom

----------

## tld

I just noticed this in the server logs from before I rebooted. Seems like it may be related:

```
Sep 28 00:26:52 mythback kernel: nfsd: last server has exited, flushing export cache

Sep 28 00:26:52 mythback kernel: klogd 1.5.1, ---------- state change ---------- 

Sep 28 00:26:52 mythback kernel: Loaded 33765 symbols from 1 module.
```

Tom

----------

## tld

Interesting. The above was in /var/log/messages, and I see this in /var/log/syslog:

```
Sep 28 00:26:52 mythback rpc.mountd[1535]: Caught signal 15, un-registering and exiting.

Sep 28 00:26:52 mythback kernel: nfsd: last server has exited, flushing export cache

Sep 28 00:26:52 mythback kernel: klogd 1.5.1, ---------- state change ---------- 

Sep 28 00:26:52 mythback kernel: Loaded 33765 symbols from 1 module.
```

EDIT: I had the results of showmount here but I was running that from the backend to the frontend, which is obviously backwards. This looks OK:

```
showmount -e mythback

Export list for mythback:

/video/tom/v        192.168.1.0/255.255.255.0

/video              192.168.1.0/255.255.255.0

/video/remote_media 192.168.1.0/255.255.255.0
```

Any help would be appreciated...getting desperate here. I'm about out of ideas.

Tom

----------

## tld

I'm not sure if this is what I should expect to see from this command (run on the frontend to the backend):

```
rpcinfo -p mythback

   program vers proto   port  service

    100000    4   tcp    111  portmapper

    100000    3   tcp    111  portmapper

    100000    2   tcp    111  portmapper

    100000    4   udp    111  portmapper

    100000    3   udp    111  portmapper

    100000    2   udp    111  portmapper

    100024    1   udp  57306  status

    100024    1   tcp  47525  status

    100005    1   udp  53615  mountd

    100005    1   tcp  34377  mountd

    100005    2   udp  46426  mountd

    100005    2   tcp  60843  mountd

    100005    3   udp  57943  mountd

    100005    3   tcp  53509  mountd

    100003    3   tcp   2049  nfs

    100021    1   udp  43696  nlockmgr

    100021    3   udp  43696  nlockmgr

    100021    4   udp  43696  nlockmgr

    100021    1   tcp  39139  nlockmgr

    100021    3   tcp  39139  nlockmgr

    100021    4   tcp  39139  nlockmgr
```

If anyone has any idea as to whether that look OK let me know.

Tom

----------

## tld

I've read about removing entries from /var/lib/nfs/rmtab and tried that...I just get the same error and a line added back into that file. Wow wow wow. Like the subject says. HELP!

Going to look at this again in the morning.

Tom

----------

## tld

GOT IT!...Couldn't sleep. A few days ago my world update did this:

```
[ebuild     U  ] net-fs/nfs-utils-2.4.1-r1::gentoo [2.3.3::gentoo] USE="ipv6 libmount nfsidmap nfsv4 tcpd uuid -caps -junction -kerberos -ldap -nfsdcld -nfsv41 (-selinux)" 890 KiB
```

THAT was the culprit. I discovered that after stumbling on this:

https://www.linuxquestions.org/questions/slackware-arm-108/anyone-having-nfs-trouble-4175658142/

Though that talks about arm. No clue of that. This is on a 32 bit x86 system. I just downgraded the client and server to net-fs/nfs-utils-2.3.3 and all's good. I could about scream. No clue if the issue is client, server, or both. Maybe it's a 32-bit only issue(?). Will worry about logging bugs after I enjoy my weekend.

Tom

----------

## krinn

https://forums.gentoo.org/viewtopic-t-1101848-highlight-nfs.html

you remind me this, but i couldn't help them in that thread as the issue was glibc version related, and i'm not using this version.

All i could tell you, is that i myself have no issue with it (with nfs3 and 4 shares), and that i suspect nfs-utils to enforce better configuration of the shares rather than a bug.

```
[binary   R    ] net-fs/nfs-utils-2.4.1::gentoo  USE="libmount nfsidmap nfsv4 tcpd uuid -caps -ipv6 -junction -kerberos -ldap -nfsdcld -nfsv41 (-selinux)" 0 KiB

Portage 2.3.73 (python 3.6.9-final-0, default/linux/amd64/17.1, gcc-9.2.0, glibc-2.28-r6, 4.14.67 x86_64)

```

----------

## Anon-E-moose

I don't run nfs at all, but krinn may be right about configuration.

I know that I've had to change configuration items with samba over the years, because of internal changes. 

The same with gcc/g++ enforcing things that it was lax about in the past.

I would look at the change log for the newer nfs-utils and see what it has to say vs the one that works.

----------

## mike155

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

----------

## krinn

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e1c9516d14cfe0bf2a9a9b4023780704eed00ecd

```
+This fixes the client side error "Stale file handle" when mounting from

+a server running Arch Linux ARM.
```

looks more like your issue, coming in -r2

----------

## tld

 *krinn wrote:*   

> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e1c9516d14cfe0bf2a9a9b4023780704eed00ecd
> 
> ```
> +This fixes the client side error "Stale file handle" when mounting from
> 
> ...

 Thanks!...and thanks everyone for the replies!

Putting that patch in my user patch directory for the existing nfs-utils-2.4.1-r1 on the server side (the client is OK as-is) does in fact fix this. I'm confused as to why everything refers to ARM around this. Both systems in my case are x86. By the way, except for having ipv6 enabled (which wasn't actually intentional), my USE flags are identical to yours.

I see this is related to large file support, which makes sense given that my server is 32 bit, and I do in fact have files in excess of 3 GB in size. I'm sure that's why I ran into this.

Thanks again!

Tom

----------

## krinn

 *tld wrote:*   

> I'm confused as to why everything refers to ARM around this. Both systems in my case are x86. By the way, except for having ipv6 enabled (which wasn't actually intentional), my USE flags are identical to yours.

 

I think all systems are affected, must have been found on arm first, but the bug is not trigger on systems where it's default enable

----------

