8.04 & 8.10 nfs clients report "internal error" when attempting to mount NFS exports

[James Jones]

Fix is described in comment #23

NOW:
*ubuntu since 7.11 - meaning at the moment 8.04 and 8.10 releases can't reliably mount NFS exports without getting "mount.nfs: internal error" if done from the command line.

If the mount request is in /etc/fstab it stops KDE loading and the system becomes unuseable (unless you know to open another TTY session).

The only workaround (for most people) is to set the mount to "noauto" in /etc/fstab and try to mount it until it succeeds at the command prompt when the system is booted.

WAS:
Using Ubuntu Studio based on Hardy Heron beta, 64-bit w/AMD Athlon 64 x2. The other computer involved is a 32-bit Sempron running Gutsy Gibbon. I followed instructions on http://czarism.com/easy-peasy-ubuntu-linux-nfs-file-sharing to make a directory on the Gutsy system availalble on the Hardy beta system, and got the following message when I attempted the mount:

mount.nfs: internal error

I double checked the commands and the IP addresses/ranges involved, and they appear to be correct.

At the Gutsy end: nfs-common and nfs-kernel-server are 1:1.1.1~git-20070709-3ubuntu1, portmap is 6.0-1ubuntu1.

At the Hardy end: 1:1.1.2-2ubuntu2 and 6.0-4 for the same packages, respectively.

[Owen PG (owen-pg)]

I just installed nfs-common on kubuntu 8,04 64 bit (final release) and get nfs reporting internal error on reboot and on mount -a having added a couple of lines to /etc/fstab - these lines were lifted straight from a previous 7.10 installation:

root@k80464:/home/user# cat /etc/fstab

# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# /dev/sda1
UUID=6be0821c-1446-45ee-b344-16117329c123 / ext3 relatime,errors=remount-ro 0 1
# /dev/sda5
UUID=977973f0-44d4-4f2c-8acb-0af5dd0c4869 none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto,exec,utf8 0 0
192.168.20.130:/media /mount/media nfs rsize=32768,wsize=32768,proto=tcp,noatime,timeo=14,intr 0 0
192.168.20.130:/Photos /mount/photos nfs rsize=32768,wsize=32768,proto=tcp,noatime,timeo=14,intr 0 0
192.168.20.130:/Software /mount/software nfs rsize=32768,wsize=32768,proto=tcp,noatime,timeo=14,intr 0 0
root@k80464:/home/user#

root@k80464:/home/user# mount -a
mount.nfs: internal error
root@k80464:/home/user#

root@k80464:/# ls -al /mount
total 20
drwxr-xr-x 5 owen root 4096 2008-04-25 17:03 .
drwxr-xr-x 23 root root 4096 2008-04-25 17:03 ..
drwxrwxrwt 10 owen 2000 4096 2008-04-10 22:55 media
drwxr-xr-x 2 owen root 4096 2008-04-25 17:03 photos
drwxrwxrwx 7 owen users 4096 2008-03-08 14:36 software
root@k80464:/#

The odd thing is, the data under the mount point is there . . .

root@k80464:/# ls -al /mount
total 20
drwxr-xr-x 5 owen root 4096 2008-04-25 17:03 .
drwxr-xr-x 23 root root 4096 2008-04-25 17:03 ..
drwxrwxrwt 10 owen 2000 4096 2008-04-10 22:55 media
drwxr-xr-x 2 owen root 4096 2008-04-25 17:03 photos
drwxrwxrwx 7 owen users 4096 2008-03-08 14:36 software
root@k80464:/# ls -al /mount/media
total 76
drwxrwxrwt 10 owen 2000 4096 2008-04-10 22:55 .
drwxr-xr-x 5 owen root 4096 2008-04-25 17:03 ..
-rwxrwxr-x 1 owen 2000 12292 2008-04-23 20:21 .DS_Store
drwxrwxr-x 16 owen 2000 4096 2007-09-21 10:56 DVDs
drwxrwxr-x 49 owen 2000 8192 2008-04-08 20:55 FLAC-CDs
drwxrwxr-x 273 owen 2000 8192 2008-04-23 19:53 FLAC-OGG
drwxrwxr-x 2 owen 2000 4096 2008-04-10 22:55 ISO-DVD
drwxrwxr-x 216 owen 2000 8192 2007-12-14 14:36 MP3s
drwxrwxrwx 3 owen users 4096 2008-04-22 06:25 Recycle Bin
drwxrwxr-x 4 owen 2000 4096 2007-12-20 09:43 .Trash-1010
drwxrwxr-x 9 owen 2000 4096 2007-05-18 09:36 .Trash-owen

[Owen PG (owen-pg)]

I remembered that there were time-out errors / warnings in Adept of ??? not installed due to breaking dependencies. Now this was the first day of 8.04 avqailability and all the download servers were being hammered and refusing connections.

I just did the following and now have a working NFS client.

#> apt-get remove portmap nfs-common

#> apt-get autoremove

#> apt-get update

#> apt-get upgrade

#> apt-get install portmap nfs-common

I then uncommented out the appropriate lines from /etc/fstab leaving this as an exqample:

192.168.20.130:/media /mount/media nfs auto,rsize=32768,wsize=32768,proto=tcp,noatime,timeo=14,intr 0 0

Lastly was

#> mount -a

And everything works.

I assume that since there's no updates to the 8.04 code that my problems were due to time-outs on the code installation causing problems.

[toer (tore-ericsson)]

After update of Kubuntu Gutsy to Kubuntu Hardy:

1. Automount at startup according to fstab started to function (it failed in Gutsy, see Bug #45842).

2. "sudo mount -a" that had to be used manually in Gutsy was ok, but now with Hardy it issues "mount.nfs: internal error" (this takes a lot of time) instead of normal diagnostics like "already mounted" or "... unavailible" etc. Mounting individually an already mounted performs as expected, that is, the mount command acts as expected if not with the -a option.

I applied the procedure described above by Owen PG with no success, the error remains.

Example with an "old Gutsy-tested" fstab:
Attempting "sudo mount -a" with 4 unmounted enties in fstab where 2 are unavailible does mount the two possible and issues "mount.nfs: internal error" twice. A subsequent "sudo mount -a" with the 2 mounted and the 2 unavailible still issues "mount.nfs: internal error" twice.

Conclusion: The "mount -a" command does probably function as expected but is remarkably slowed down and issues an unexpected error message "mount.nfs: internal error" for unknown reasons in Hardy Heron.

[Trent Telfer (unnaturalhigh)]

I am additionally having this problem with a server running Ubuntu 8.04 and the client running Ubuntu 8.04. I am using the latest nfs-common and portmap. Even after attempting the solution proposed by Owen PG, I still had no success. If any additional information is required please don't hesitate to ask. Also I should mention both computers have ufw enabled with nfs forwarded on both.

[Owen PG (owen-pg)]

Unfortunately, I discovered that my "fix" was nothing of the sort. The PC still has intermittent errors at boot-time at the rc.local and nfs sections. Sometimes one of the mounts will happen but not thhe others from the same nfs server.

Sorry for getting hopes up (including my own).

[Ulli Horlacher (framstag)]

I run into the same problem:

pussy (the client) is an AMD 64X2 PC with 64 bit Ubuntu 8.04.

rusnas1a-n1 is a Netapp FAS 3070 running ONTAP 7.2.1 (a multi-million-Dollar
NAS/SAN):

root@pussy:/# mount.nfs rusnas1a-n1:/vol/rusnas1a_n1_vol3/sw /nfs/rusnas/sw
mount.nfs: internal error

root@pussy:/# strace mount.nfs rusnas1a-n1:/vol/rusnas1a_n1_vol3/sw /nfs/rusnas/sw
(...)
mount("rusnas1a-n1:/vol/rusnas1a_n1_vol3/sw", "/nfs/rusnas/sw", "nfs", 0, "addr=129.69.201.80") = -1 EIO (Input/output error)
write(2, "mount.nfs: internal error\n", 26mount.nfs: internal error) = 26
exit_group(32) = ?

The same client (hardware) with Ubuntu 7.10 can NFS-mount the Netapp
server without any problems.

Mounting an Ubuntu-PC works ok, too.
fex is an Intel Xeon based VMware virtual PC running Ubuntu 7.10:

root@pussy:/# mount.nfs fex:/export/sw /nfs/fex/sw
root@pussy:/# df /nfs/fex/sw
Filesystem 1K-blocks Used Available Use% Mounted on
fex:/export/sw 82567232 24686464 53686592 32% /nfs/fex/sw
root@pussy:/# mount | grep fex
fex:/export/sw on /nfs/fex/sw type nfs (rw,addr=129.69.1.11)

Only the Netapp NFS-Server is not mountable from Ubuntu 8.04. But this is
our central storage device!
"internal error" does not help much in finding the reason of the problem.

[JLB (news-eserver)]

I got the same error:

root@eserver:/etc# mount /media/dreambox
mount.nfs: internal error

This occured only after the last update of Hardy Heron.

After rebooting the box, it didn't respond, and i had to disable the nfs mounts ....

[Ulli Horlacher (framstag)]

Update:

I tried mount.nfs from Ubuntu 7.10 (installed in /usr/local/sbin/) :

root@pussy:/# /usr/local/sbin/mount.nfs -V
mount.nfs (linux nfs-utils 1.1.0)

root@pussy:/# /usr/local/sbin/mount.nfs rusnas1a-n1:/vol/rusnas1a_n1_vol3/sw /nfs/rusnas/sw -v -o proto=tcp
mount.nfs: trying 129.69.201.80 prog 100003 vers 3 prot tcp port 2049
mount.nfs: trying 129.69.201.80 prog 100005 vers 3 prot tcp port 4046
rusnas1a-n1:/vol/rusnas1a_n1_vol3/sw on /nfs/rusnas/sw type nfs (proto=tcp)

root@pussy:/# mount | grep /sw
rusnas1a-n1:/vol/rusnas1a_n1_vol3/sw on /nfs/rusnas/sw type nfs (rw,proto=tcp,addr=129.69.201.80)

The mount was successfull!

Again, mount.nfs from Ubuntu 8.04 still fails:

root@pussy:/# umount /nfs/rusnas/sw

root@pussy:/# /sbin/mount.nfs -V
mount.nfs (linux nfs-utils 1.1.2)

root@pussy:/# /sbin/mount.nfs rusnas1a-n1:/vol/rusnas1a_n1_vol3/sw /nfs/rusnas/sw -v -o proto=tcp
mount.nfs: timeout set for Tue May 13 15:19:57 2008
mount.nfs: text-based options: 'proto=tcp,addr=129.69.201.80'
mount.nfs: internal error

Dito with proto=udp

[Miek Gieben (miek)]

tracing the mount call gives:

This is only the last part:

port=htons(53), sin_addr=inet_addr("127.0.0.1")}, [16]) = 259
close(3) = 0
gettimeofday({1211135677, 873940}, NULL) = 0
mount("toaster.xxxxxx.yy:/vol/music", "/nfs/toaster.xxxxx.yy", "nfs", 0, "addr=2xx.1xx.2xx.2x") = -1 EIO (Input/output error)
write(2, "mount.nfs: internal error\n", 26mount.nfs: internal error) = 26
exit_group(32) = ?
Process 12870 detached

Looks like the mount syscal fails.

[PJ (eespjl)]

+1

[phelan (christian-hesch)]

I'm receiving the same error: Using ssh-tunneling and

 localhost:/mnt/raid/servermarktplatz /marktplatz nfs noauto,rw,hard,intr,proto=tcp,port=8888,mountport=7777,nolock 0 0

in the fstab work without any problems on Ubuntu 7.10 and on Fedora 6 and 7. I've tried also on the command line:

 mount.nfs localhost:/mnt/raid/servermarktplatz /marktplatz -v -o proto=tcp,port=8888,mountport=7777 -v

which works fine on the mentioned distributions. Unfortunately I received on 8.04:

 mount.nfs: timeout set for Tue May 20 15:51:30 2008
 mount.nfs: text-based options: 'proto=tcp,port=8888,mountport=7777,addr=127.0.0.1'
 mount.nfs: internal error

and without the optional arguments yields:

 mount.nfs localhost:/mnt/raid/servermarktplatz /marktplatz -v
 mount.nfs: timeout set for Tue May 20 15:41:22 2008
 mount.nfs: text-based options: 'addr=127.0.0.1'
 mount.nfs: mount to NFS server 'rpcbind' failed: RPC Error: Program not registered
 mount.nfs: internal error

which is OK since I've received: 'mount request from unknown host xxx.xxx.xxx.xxx for /mnt/raid (/mnt/raid)' in the log-file on the file
server. I get no log on the file server for a mount request for the first attempt.

[Miek Gieben (miek)]

This:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477503

seems related. And it supposedly provides a fix.

[DaveAbrahams (boostpro)]

Me too. Please apply the patch, Ubuntu!

[Miek Gieben (miek)]

[ Quoting DaveAbrahams in "[Bug 213444] Re: Hardy Heron nfs (c"... ]
> Me too. Please apply the patch, Ubuntu!

I tried that patch. It removed the 'internal error', but I still
couldn't mount the remote NFS directory.

--
grtz,
 - Miek
 GPG Key ID: 3880 D0F6 http://www.miek.nl/

[Barry Page (barry-page)]

It works just fine for me so long as the remote server allows UDP and TCP.

[Ulli Horlacher (framstag)]

> It works just fine for me so long as the remote server allows UDP and TCP.

Our netapp NFS server does both, UDP and TCP, but mount.nfs from Ubuntu 8.04 still says: "internal error"

It IS a bug for mount.nfs (nfs-utils 1.1.2, nfs-common 1:1.1.2-2ubuntu2) from Ubuntu 8.04,
because mount.nfs (nfs-utils 1.1.0, 1:1.1.1~git-20070709-3ubuntu1) from Ubuntu 7.10 can mount the server without problems!

Both mount.nfs programs were executed on Ubuntu 8.04 with the same parameters!

[Fernando Chávez (nandoc)]

Hi,
Is it possible to install nfs-???? previously working version on 8.04??
TIA

[Tom D (launchpad-mail-elistia)]

I upgraded from Gutsy to Hardy yesterday and am experiencing the same problem.

This is a major problem as I now cannot access any NFS shares from my server. I have a laptop still running Gutsy which has no problem.
Am running nfs-common version 1:1.1.2-2ubunt.

Is this problem likely to be fixed soon through the update system? If not, does anyone have any suggestions (as asked above) as to the best way to return system to the last working version (preferably in such a way that it will be updated to a new working version when that becomes available)

Don't really want to patch myself and recompile unless I have to.

[bill (hammack)]

I too can verify that this is indeed a bug -- and a most annoying one at that. For several years now I've used an NFS server to share my files with laptop, two offices, etc. The laptop (which runs Libranet!) and the first office computer that runs dapper work fine with sshtunnelling via tcp (you DON'T need udp!). I've installed Hardy on the new machine at the second office and see the errors reported above -- "internal error". And no it isn't a firewall issue: My laptop works fine in the second office. This needs to be fixed. How do we change its status to important?

[ante (c-launchpad-ursus-ath-cx)]

I am a Debian/testing user and I had the same problem today, even though I can't figure out what had changed, as I updated packages on the client as well as on the server.
However I detected that in /etc/default/portmap on the server I had this:

# If you want portmap to listen only to the loopback
# interface, uncomment the following line (it will be
# uncommented automatically if you configure this
# through debconf).
OPTIONS="-i 127.0.0.1"

I don't know, whether this had been configured before or not, but after disabling this OPTIONS line and restarting the portmap service I could mount the NFS shares again.Maybe this helps in locating the source of the problem, but maybe it is just some other kind of problem, especially because you have updated the client and not the server.

[ante (c-launchpad-ursus-ath-cx)]

I understood now that this configuration provided a workaround in case UDP and TCP is available on a local network and may not work if it is connected via an SSH tunnel.

[Fernando Chávez (nandoc)]

Hello Again,
I am really new about Ubuntu. I have solved my problem today, it was a simple fix. It is working in all my machines (1 Ubuntu 8.04 server, 3 Ubuntu 8.04, 1 Ubuntu 7.10 and a Laptop 8.04). All of them finally working. This what I did:
I realized that right clicking on the NM applet on the notification area and choosing "network information" I was having a different one from the one I had stated in "/etc/network/interfaces" in order to address nfs in clients fstab. The IP displayed was not the one on interfaces.
So I configured "Static configuration" (by clicking on network-managet icon in notification area and choosing "Static configuration..."), after unblocking it, etc, etc., then clicked on "Connections" tab and then on "Wired connection" and then clicked on "Properties" button; entered static IP, netmask, gateway and clicked on "OK" button.
Then Rebooted and my connections were back.
For my case it seems that NM was not reading "/etc/network/interfaces" since I had configured client's "fstab" to mount based on my so "static" IP.
Hope this help,
Fernando
Lima, PERU

[bill (hammack)]

This post explains how to implement a workaround. The process below creates a .deb; I have attached that file ...
if it works for you then no need to go through all this. To test it implement STEP #1 and then go to STEP #6 and continue from there.
Use, of course, at your own risk.

This bug is the same
as debian bug #477503 as described at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477503 entitled
"nfs-common: tcp mount require udp." At that URL Frank Kingswood
(message #40) noted the correction that needs to be made in the source
code, although he did not give details how to implement it. In this post
I explain how to change the code and then recreate the deb for your
system. If you are doing ssh tunnelling this should be a completely
functional workaround.

The basic idea is this: 1) the problem is in the file mount.c that
creates /sbin/mount.nfs -- this mount.nfs doesn't work for nfs using
only tcp - the version of NFS implemented in Hardy errs in requiring
that both UDP and TCP ports be used. This isn't necessary; and in fact
in the case of using an ssh tunnel over tcp using udp is forbidden. 2)
To fix this one needs to download the source code, amend the code in
mount.c, then recreate the *.deb package and reinstall. I've spelled
out the steps fully below so that any level user should be able to do
this ... there is nothing difficult in it at all, it is just
lengthy. The package affected is called nfs-common .... specifically
nfs-common-_1.1.2-2ubuntu2.1_i386.deb. (See
http://packages.ubuntu.com/hardy/net/nfs-common for details on the
package if you like.)

STEP 1: REMOVE nfs-common [Note # indicates superuser; $ regular user]

     As superuser (or use sudo)

     # apt-get remove nfs-common

STEP 2: DOWNLOAD SOURCE

     a. Make a directory nfs-correct

 Go to the directory of your choice and type

 $ mkdir nfs-correct

     b. Download source

 $ cd nfs-correct [you should now be in nfs-correct, type pwd
         to check if you like]

        $ apt-get source nfs-common

STEP 3: DOWNLOAD TOOLS NEEDED FOR REBUILDING .DEB

     a. As superuser type [or use sudo]

 # apt-get install devscripts build-essential fakeroot

    b. Create dependencies

         as superuser type this (or use sudo)

  # apt-get build-dep nfs-common

  [For details on rebuilding debian packages see
  http://www.debian-administration.org/articles/20]

STEP 4: AMEND SOURCE CODE

     a. You will see a subdirectory nfs-utils-1.1.2 under nfs-correct

 type:

 cd nfs-utils-1.1.2/utils/mount

     b. Open mount.c with your favorite text editor [I use emacs]

        Find this sequence of lines:

 nfs_mount_data_version = NFS_MOUNT_VERSION;
    else
        if (kernel_version > MAKE_VERSION(2, 6, 22))
             string++;
}

 Change it so it reads:

        nfs_mount_data_version = NFS_MOUNT_VERSION;
    else
        if (kernel_version > MAKE_VERSION(2, 6, 22))
             printf("/usr/local/sbin/mount.nfs: not using string\n");
             /* string++; */
}

     c. Save this file

STEP 5: CREATE NEW .DEB

     Return to the subdirectory nfs-utils-1.1.2

     Within this subdirectory type as root (or using sudo)

     # debuild -us -uc

     Wait as...

[Tom D (launchpad-mail-elistia)]

Bill, thanks very much for this. Will install your .deb as soon as I get a chance and report back with results. :-)

[Tom D (launchpad-mail-elistia)]

Had to compile myself (following Bill's instructions) for my AMD64 system. Works perfectly :-)
Have attached .deb for any 64bit users out there.

Very many thanks Bill, you have avoided me having to reinstall Gutsy.

[bill (hammack)]

Tom brings up a good point: I should have noted that my .deb is only for i386 .... thus the detailed instructions for other systems.

[Ulli Horlacher (framstag)]

Sorry, but the deb-rebuild does not work for me.
I have followed exactly the instructions, but I get:

root@pussy:/tmp/nfs-correct/nfs-utils-1.1.2# debuild -us -uc
(...)
dh_install
dh_installdocs -A
dh_installdocs -pnfs-common debian/README.Debian.nfsv4
install -m 0755 debian/nfs-common.init debian/nfs-common/etc/init.d/nfs-common
install -m 0755 debian/nfs-kernel-server.init debian/nfs-kernel-server/etc/init.d/nfs-kernel-server
dh_installman
dh_link
dh_installchangelogs ChangeLog
dh_strip
dh_compress
dh_fixperms
chmod u+s debian/nfs-common/sbin/mount.nfs
dh_installdeb
dh_shlibdeps
dpkg-shlibdeps: warning: debian/nfs-kernel-server/usr/sbin/rpc.svcgssd shouldn't be linked with libdl.so.2 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/nfs-kernel-server/usr/sbin/rpc.svcgssd shouldn't be linked with libldap_r-2.4.so.2 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/nfs-kernel-server/usr/sbin/rpc.svcgssd shouldn't be linked with libgssapi_krb5.so.2 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/nfs-kernel-server/usr/sbin/rpc.svcgssd shouldn't be linked with libkrb5.so.3 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/nfs-kernel-server/usr/sbin/rpc.svcgssd shouldn't be linked with libk5crypto.so.3 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/nfs-kernel-server/usr/sbin/rpc.svcgssd shouldn't be linked with libcom_err.so.2 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/nfs-kernel-server/usr/sbin/exportfs shouldn't be linked with libwrap.so.0 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/nfs-common/usr/sbin/rpc.gssd shouldn't be linked with libdl.so.2 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/nfs-common/usr/sbin/rpc.gssd shouldn't be linked with libgssapi_krb5.so.2 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/nfs-common/usr/sbin/rpc.gssd shouldn't be linked with libk5crypto.so.3 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/nfs-common/usr/sbin/rpc.idmapd shouldn't be linked with libnsl.so.1 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/nfs-common/usr/sbin/rpc.idmapd shouldn't be linked with librt.so.1 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/nfs-common/usr/sbin/rpc.idmapd shouldn't be linked with libresolv.so.2 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/nfs-common/usr/sbin/rpc.idmapd shouldn't be linked with libldap_r-2.4.so.2 (it uses none of its symbols).
dh_gencontrol
dh_md5sums
dh_builddeb
warning, `debian/nfs-kernel-server/DEBIAN/control' contains user-defined field `Original-Maintainer'
dpkg-deb: ignoring 1 warnings about the control file(s)
dpkg-deb: building package `nfs-kernel-server' in `../nfs-kernel-server_1.1.2-2ubuntu2.1_amd64.deb'.
warning, `debian/nfs-common/DEBIAN/control' contains user-defined field `Original-Maintainer'
dpkg-deb: ignoring 1 warnings about the control file(s)
dpkg-deb: building package `nfs-common' in `../nfs-common_1.1.2-2ubuntu2.1_amd64.deb'.
 dpkg-genchanges
dpkg-genchanges: not including original source code in upload
dpkg-buildpackage (debuild emulation): binary and diff upload (original s...

[bill (hammack)]

Ulli, Interesting. Could you post the following:

1. What system are you doing this on -- i386, AMD64, Sprac, Mac OS x ?

2. Is it a fresh install of Hardy ... indeed is it hardy?

3. Is your system up to date? Have all updates been applied?

A quick guess ... but it is only that ... is that the dependencies aren't right. I'm not familiar with the error message you got.

[Ulli Horlacher (framstag)]

See https://bugs.launchpad.net/ubuntu/+bug/213444/comments/6

[phelan (christian-hesch)]

Just installed the amd64 .deb file from Tom. Works great with the ssh tunnel, Thanks a lot.

[[e-mail] (the-emaj)]

I used dpkg-divert to avoid upgrade could delete the patch.

As root:

dpkg-divert --divert /sbin/mount.nfs.bak --rename /sbin/mount.nfs && cp /sbin/mount.nfs.bak /sbin/mount.nfs

This works for me
Hope helps.

[Parazythum (parazythum)]

Hi,

I had the same problem, my NFS server machine is under Ubuntu Hardy 64bit, and my client machine under Kubuntu Hardy 32bit. I had a hard time figuring out what was wrong, but after a while I got it : I had added a new nic, and had changed all the IP addresses on my systems. I had changed before /etc/hosts.allow. Dang ! That was it : the old addresses were still there. I changed them, restarted all the required services and it worked.

Don't forget also to comment out the OPTIONS line pointing to 127.0.0.1 in /etc/default/portmap !

[Lucio Pileggi (pileggi)]

Same problem here,
my client is running Ubuntu 8.04.1 and using latest nfs-common package (Version: 1:1.1.2-2ubuntu2).
Trying to mount a remote NFS share the system reply with this error:

#mount -a
mount.nfs: mount to NFS server 'rpcbind' failed: System Error: Connection refused
mount.nfs: internal error

Looks like problem is related to a system update, the client was able to mount the same NFS share right after the installation.

Here are the last lines of a "strace mount -a" output:

open("/etc/fstab", O_RDONLY|O_LARGEFILE) = 3
umask(022) = 077
fstat64(3, {st_mode=S_IFREG|0644, st_size=663, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7cf9000
read(3, "# /etc/fstab: static file system"..., 4096) = 663
read(3, "", 4096) = 0
close(3) = 0
munmap(0xb7cf9000, 4096) = 0
readlink("/proc", 0xbf9b6087, 4096) = -1 EINVAL (Invalid argument)
umask(077) = 022
open("/etc/mtab", O_RDONLY|O_LARGEFILE) = 3
umask(022) = 077
fstat64(3, {st_mode=S_IFREG|0644, st_size=471, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7cf9000
read(3, "/dev/sda2 / ext3 rw,relatime,err"..., 4096) = 471
read(3, "", 4096) = 0
close(3) = 0
munmap(0xb7cf9000, 4096) = 0
getcwd("/", 4095) = 2
readlink("/myhost.it:", 0xbf9b6057, 4096) = -1 ENOENT (No such file or directory)
readlink("/homenfs", 0xbf9b6087, 4096) = -1 EINVAL (Invalid argument)
stat64("/sbin/mount.nfs", {st_mode=S_IFREG|S_ISUID|0755, st_size=65520, ...}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7e1a768) = 6455
wait4(-1, mount.nfs: mount to NFS server 'rpcbind' failed: System Error: Connection refused
mount.nfs: internal error
[{WIFEXITED(s) && WEXITSTATUS(s) == 32}], 0, NULL) = 6455
--- SIGCHLD (Child exited) @ 0 (0) ---
exit_group(32) = ?
Process 6454 detached

[Paul Abrahams (abrahams)]

The problem of mount.nfs producing an internal error also showed up for me in OpenSUSE 11.0, when it was not in previous versions of OpenSUSE. So it must be originating in some code release that's common to both OpenSUSE and Ubuntu. It's also been reported for Fedora.

And it's very nasty.

[Alexi Girgis (alexi-girgis)]

Hello,

Thanks for the patches bill/Tom.

the problem I had was the repo wanted to upgrade top the latest version, even when I did "lock version" from Synaptic. Rather than using dpkg-divert as was suggested above, I re-built the packages with the version:

1.1.2-2ubuntu2.1.1

instead of

1.1.2-2ubuntu2.1

I hope this is ok and does not break the naming conventions with the next update in the repos.

[Alexi Girgis (alexi-girgis)]

Here is the amd64 version (see above comment)

[elektronaut (hendrik-04)]

The patch doesn't work for me. mount.nfs is reporting timeout errors.

[Alexi Girgis (alexi-girgis)]

Sorry, I didn't make the patch. I just changed the version so that
update-manager does not overwrite it.

On Thu, Aug 28, 2008 at 6:55 AM, elektronaut <email address hidden> wrote:

> The patch doesn't work for me. mount.nfs is reporting timeout errors.
>
> --
> Hardy Heron nfs (client) reports internal error when I attempt to mount
> with NFS
> https://bugs.launchpad.net/bugs/213444
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in "nfs-utils" source package in Ubuntu: Confirmed
>
> Bug description:
> Using Ubuntu Studio based on Hardy Heron beta, 64-bit w/AMD Athlon 64 x2.
> The other computer involved is a 32-bit Sempron running Gutsy Gibbon. I
> followed instructions on
> http://czarism.com/easy-peasy-ubuntu-linux-nfs-file-sharing to make a
> directory on the Gutsy system availalble on the Hardy beta system, and got
> the following message when I attempted the mount:
>
> mount.nfs: internal error
>
> I double checked the commands and the IP addresses/ranges involved, and
> they appear to be correct.
>
> At the Gutsy end: nfs-common and nfs-kernel-server are
> 1:1.1.1~git-20070709-3ubuntu1, portmap is 6.0-1ubuntu1.
>
> At the Hardy end: 1:1.1.2-2ubuntu2 and 6.0-4 for the same packages,
> respectively.
>

[Wesley Schwengle (wesleys)]

@bill from https://bugs.launchpad.net/ubuntu/+bug/213444/comments/23

Thanks for the patch and the instructions. It solved the problem for me.

[Hans Persson (ubuntu-unicorn)]

I have the same problem.

Is there a fix for this that doesn't involve changing the code and recompiling? I would consider this to be a high-priority problem.

[bill (hammack)]

There is no other solution that I know of. If you are running Hardy on an i386 you can use the .deb that I created. If it is for some other system you'll need to change the code. It takes a little bit of time, but is perfectly straightforward.

[Hans Persson (ubuntu-unicorn)]

I've done a little more testing.

The patched mount (on an Intrepid machine) can mount a share from another Intrepid system, but it can't mount a share from an identically-configured Edgy system. It appears that the version of the server is also relevant.

[bill (hammack)]

I don't know if this is helpful but ... I run my "patched" NSF client on several machine all of which can mount shares served by an old version of debian -- actually Libranet ... google that one to see how old the distribution is!

[costales (costales)]

I changed my router and the IP is different now.
I had this error when I tried mount with nfs:
mount.nfs: mount to NFS server 'rpcbind' failed: RPC Error: Program not registered

I fixed it, changing in /etc/host.allow the range to the new IP of the server computer.
Can you try it?
Best regards.

[Owen PG (owen-pg)]

I have a fully patched Kubuntu 8.04, 32 bit workstation (Hardy Heron) that still uses the "noauto" option in /etc/fstab for NFS mounts.

I still get "internal error" sometimes when mounting from the command line as superuser. One mount point usually goes through OK first time whilst another usually requires 3 mount attempts. Odd thing is, the exports are on the same server.

[JasonBurns (47-m450n-47)]

I have an NFS server that I recently upgraded to 8.10. After the upgrade, NFS wouldn't work anymore, or at least my 8.04.1 x64 main desktop couldn't connect to it.

192.168.0.200:/home/jason/Share /home/jason/Sync nfs rsize=8192,wsize=8192,timeo=14,intr 0 0

That's the line in my fstab that used to work perfectly.

[Owen PG (owen-pg)]

Jason,

My workaround since 8.04 has been to add the "noauto" option to the line in /etc/fstab - and then mount it from a command prompt when the desktop is booted and logged in. If it fails the first time, try again. In your case:
"sudo mount /home/jason/Sync"

FWIW, Not that I'm an expert but for reliability and then to speed it back up, I use TCP rather than UDP and increase the window sizes. This leaves me with the following options:

rsize=32768,wsize=32768,proto=tcp,noauto

You might want to try them as well as noauto.

Good luck,

Owen

[JasonBurns (47-m450n-47)]

Well I edited fstab and tried to do a mount again but it got the same error. I'm going to shut my PC down for the night and I'll try it again tomorrow if I have time. Maybe it will work after a restart.

I also brought my 8.10 laptop home from work, I'll try connecting to the NFS from it and see what happens.

[Owen PG (owen-pg)]

If it fails to mount the first time, try again. In your case:
"sudo mount /home/jason/Sync"

[Christoph Cullmann (cullmann)]

We had the same problem, we solved it by disabling the networkmanager and either assigning static IPs or using the old approach of dhcp via interfaces not networkmanager...

[Paul Abrahams (abrahams)]

The NFS mount problem has been around now for quite a while. I think I first reported it (under another number) a couple of years ago. It must be a bug since it should not be possible for a user to provoke an internal error no matter what he or she does. And it's been encountered by quite a number of people -- I assume that the reporters here are only a small minority of those who've bumped into it.

Is there anyone around who has assumed responsibility for this?

[JasonBurns (47-m450n-47)]

@Owen: I saw where you posted that suggestion originally. I tried that and still got the internal error.

After a reboot it still doesn't work.

I tried to connect to it with my 8.10 laptop and got the same results using both my original configuration and the new one requested by Owen above.

@Christoph Cullmann: I don't use network-manager on my laptop, I use Wicd instead and have a static IP.

[Paul Abrahams (abrahams)]

Perhaps if no one can determine the cause of the error, it might be worthwhile to modify the code in order to produce a more revealing (to the code author, anyway) error message.

[Owen PG (owen-pg)]

@ Paul Abrahams

Supposedly the fixed code is available in Debian. It seems just not to have been picked up in *ubuntu - earlier posts in this thread seem to confirm.

Amazing things I feel, a linux distribution that can't cope with either NFS or CIFS shares. See below for details:

https://bugs.launchpad.net/ubuntu/+source/samba/+bug/211631

[Hans Persson (ubuntu-unicorn)]

Amazing that an update to nfs-common just arrived with various fixes, but without fixing this major problem that breaks previously-working systems when upgrading, especially since there's a working fix in a .deb in the ticket.

[C.Cier (c-cier)]

The problem is still there. At least in hardy which is LTS. I used NFSv4. Only one TCP port (2049) is possible between Server and Client due to a firewall.

There is a really simply workaround for this:
Specifiy port=2049 in the mount options on the client. By specifying this option rpcbind is not contacted any more by mount.nfs4, so UDP is not required anymore. Yes, I know that 2049 _is_ already the default port, but the fact that the option is explicitly set changes the behaviour of mount.nfs4.

From the manpage:
[...]
Valid options for the nfs4 file system type
port=n
The numeric value of the server's NFS service port. If the server's NFS service is not available on the specified port, the mount request fails. If this mount option is not specified, the NFS client uses the standard NFS port number of 2049 without first checking the server's rpcbind service. This allows an NFS version 4 client to contact an NFS version 4 server through a firewall that may block rpcbind requests.
[...]

Important is the _last_ part. The nfs client is supposed to try only TCP port 2049 without asking rpcbind first if the "port=" option is _NOT_ given.

But this is simply not the case. It definitly asks rpcbind which fails because UDP is blocked. So the whole mount requests times out and gives the "internal error" then.

I managed to get around this by specifing "port=2049" in the mount options. Now it seems to work. No more rpcbind errors in dmesg output. So I assume that rpcbind is not asked anymore.

So at least there is a discrepancy between the man page and the actual behaviour of NFSv4 mounts with respect to one-tcp-port-only-mounts.

[Owen PG (owen-pg)]

Following routine system updating on 4/1/09, the mounts now go through perfectly (and fast). I don't know which particular update fixed it but I can confirm that both 8.04 and 8.10 are now mounting NFS3 fine for me. How does the bug get closed as fixed?

Cheers,

Owen

[toer (tore-ericsson)]

The error appears remaining for unavailable mounts, example of the command 'mount -a' when four mounts are unavailable on the network:

[~]$ sudo mount -a
mount.nfs: internal error
mount.nfs: internal error
mount.nfs: internal error
mount.nfs: internal error

When three are available and one unavailable:

[~]$ sudo mount -a
mount.nfs: internal error

and the three available are mounted and accessible.

So far without any further digging, 'mount -a' via fstab seems to function as expected but any unavailible mount is (after about half a minute delay!) reported as an internal error.

Specifying port=2049 made no difference - this was Kubuntu Hardy 8.04.1

[C.Cier (c-cier)]

@toer:
The simple workaround I have described only works for NFSv4. Which NFS protocol version are you using?
BTW: You can also see error messages in dmesg where rpcbind states that it cannot contact the NFS server if you are using NFSv4 and if you have _not_ specified port=2049 explicitly. But again, this is only the case if you are using NFSv4 with TCP and everything else is blocked between the client and the server (mainly UDP, because of RPC).

NFSv3 by default uses the portmapper(for RPC) and UDP. NFSv4 is a very different.

@Owen:
Please do not close the bug. It is still there if you are using NFSv4 and have a UDP blocking firewall between the client and the server.
The man page (NFS4) says: "If this mount option [port=] is not specified, the NFS client uses the standard NFS port number of 2049 without first checking the server's rpcbind service."
Simply, this is not the behaviour that is described. The client does contact the server's rpcbind server (via UDP) and this fails with "internal error", although it is not supposed to do so. -> Bug

[Carlos Blanquer Bogacz (cblanquer)]

Still same issue.

I followed the link http://www.linuxconfig.org/HowTo_configure_NFS for setting up my share and the remote access.
I have set up & checked nfs on my server Kubuntu 8.10.
I did set up a connection form my client PC Ubuntu 8.10, which does not work.

These are the commands I issued:

sudo mount.nfs 192.168.1.3:/media/TV/tdt /home/carlos/LAN.tv -o port=2049
> mount.nfs: internal error

sudo mount.nfs4 192.168.1.3:/media/TV/tdt /home/carlos/LAN.tv -o port=2049
> mount.nfs4: internal error

===================
As far as I see in the bugthread there is no solution yet, is there ? Or do I operate wrongly ?
THX

[C.Cier (c-cier)]

@Carlos:

Keep in mind that NFS3 and NFS4 are very different. My workaround with the port option is only intended for NFS4. NFS4 uses a single TCP connection for communication between client and server. Portmapper (with rpcbind) is not needed for NFS4. "My" internal error (for NFS4) is caused by the fact that no UDP communication is possible between my client and my server due to a firewall. Normally, NFS4 should first try to use only the TCP connection _without_ using rpcbind(Portmapper), but this simply not the case. Concerning "my" internal error, this is a bug. The decribed behaviour only works if the port option is specified, although the man page describes exactly the opposite.

Do you get any error messages in dmesg concerning the portmapper/rpcbind during the mount request (for NFS4 mounts)?
When I get those internal error messages, they always come along with error messages from rpcbind.

Maybe there are at least two different bugs which lead to this internal error.

I think that people should clearly state if the intend to use NFS3 or NFS4.

BR
Christian

[Yannis Tsop (ogiannhs)]

Is it so difficult to solve this???

[Carlos Blanquer Bogacz (cblanquer)]

Hi
I had no opportunity to test yey (work + children) but will do it soon,
guys.

What I do not understand is wher eI catch the difference between NFS3 and
NFS4, I was assuming my command mounting "mount.nfs" corresponded to nfs3
and "mount.nfs4" was mounting nfs4, where both failed execution.

====================================================
sudo mount.nfs 192.168.1.3:/media/TV/tdt /home/carlos/LAN.tv -o port=2049
> mount.nfs: internal error

sudo mount.nfs4 192.168.1.3:/media/TV/tdt /home/carlos/LAN.tv -o port=2049
> mount.nfs4: internal error

====================================================

--
Carlos Blanquer Bogacz
_______________________________________
skype: carlosblanquerbogacz
_______________________________________

[164747 (jacquet-david)]

I run hardy on booth nfs-server and client. Running in normal mode, mounting work perfectly. Running nfs through an ssh-tunnel as described by

http://www.howtoforge.com/nfs_ssh_tunneling

Reults in an "internal error". Applying Bills workaround

https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/213444/comments/23

fixes everything. A cannot understand why this takes so long time to fix when it is just to uncomment one line of code, or is the problem more complex?

[Alexey Mentat (mentatxx)]

I had same problem, but found reason and solution.

Ubuntu NEED opened udp 111 port on server.
I have checked binds on server ( freebsd ) and found udp 11 port binded to localhost.
Just after that, I restarted rpcbind, mountd and nfsd services on my freebsd-server and all going ok :)

Thank's to wireshark - it's really helps discover problems :)

[Pat Forget (junk-spheresys)]

Had the same issue mount.nfs: internal error

spent about a day trying different things, turns out our nfs could not do a reverse lookup on the client's IP. Resolv.conf had an old server not maintained by us and went away. Added a line for all the hosts that need nfs on the /etc/hosts of nfs server. mount -a started again.

Hope this helps some of you having this issue, because it was driving me crazy.

[SonyBafbrein (sonybafbrein)]

I had this problem with the turnkey virtual appliance server's based on ubuntu. Changing nfs to nfs4 in fstab fixed it for me.

[Bryce Harrington (bryce)]

Has anyone seen this bug on any releases newer than Hardy (i.e. Lucid or Natty)? Or is it specific to hardy?

Looking at the fix described in comment #23, it's not evident to me why that fixes it, so while that code change is straightforward enough, we wouldn't want to consider it for SRU without a more detail understanding of why it's a fix.

I doublechecked the current nfs-utils package, which has the same bugged code present, so presumably either the bug still exists with newer nfs-utils releases, or the real fix was elsewhere, or the bug gets masked with newer releases (i.e. kernel > 2.6.22).

Anyway, if anyone still needs this fixed in hardy officially, the next step would be to propose a debdiff which packages the patch in question.

[Rolf Leggewie (r0lf)]

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".