On Tue, 08 Apr 2008 14:53:21 +0200, Aragorn <aragorn@chatfactory.invalid> wrote:
>Mark Hobley wrote:

>> I am using Gentoo, and I updated the system using emerge -uDA. I am no
>> longer able to mount NFS fileshares on my NFS server (running Debian).

>I may be way out of my league here, but I'm willing to point out a few
>things that may in turn lead you to resolving this problem. ;-)

>> mount neptune:/volumes/vol3a/ /volumes/vol3a/
>> mount: wrong fs type, bad option, bad superblock on
>> neptune:/volumes/vol3a/,
>> missing codepage or helper program, or other error
>> In some cases useful info is found in syslog - try
>> dmesg | tail or so

>First of all, you're probably aware that NFS comes in two versions, one of
>them being the traditional NFSv3 still used by most implementations, the
>other one being the newer NFSv4 that allows a connection over either UDP -
>as has always been the custom - or over TCP/IP, which is new.

>So I think it's important to check whether the NFS server and the client are
>both using the same NFS version and whether they are both speaking the same
>network packet protocol. This could pertain to the "wrong fs type, bad
>option, bad superblock" error message.

In the linux world, nfs4 is still considered experemental and you can't
specify it by accident. fstab has to have 'nfs4' instead of 'nfs' as the
filesystem type. You also have to build a new kernel with nfs4 support
enabled. nfsutils should still support nfs3 and the kernel should also
support nfs3 unless one went into the kernel configuration and specifically
removed nfs3 support then built a new kernel.


I played around w/ nfs4 and found its permissions scheme to be a royal PITA.
Pretty much every single file off the server was considered to be owned by
'nobody'. You have to enable another authentication protocol like kerberos
or gssd and I gave up trying to get it working. And of course, an nfs4
server can not have shared directories from two separate locations; they
have to have a common directory from which they derive.