NFS Protocol not supported when mounting from a Linux machine.

[Rene Rivera]

I'm trying to NFS mount from a Linux machine to my new OpenBSD setup and
it just doesn't work. I've run out of things to try, and I keep getting
the "Protocol not supported" error. Trying to force the NFS version:

mount_nfs -2 x.x.x.x:/mnt/export /mnt/export

Doesn't seem to work as the Linux server keeps saying:

svc: unknown version (3)

Any help appreciated.

[Matt Provost]

Post by Rene Rivera
I'm trying to NFS mount from a Linux machine to my new OpenBSD setup and
it just doesn't work. I've run out of things to try, and I keep getting
mount_nfs -2 x.x.x.x:/mnt/export /mnt/export
svc: unknown version (3)
Any help appreciated.

Did you try mounting using both tcp and udp? Also try using rpcinfo to
see which protocols/versions are supported on the server:

rpcinfo -u hostname nfs
rpcinfo -u hostname mountd
rpcinfo -t hostname nfs
rpcinfo -t hostname mountd

Matt

[Golliher, Blake]

Does showmount -e against that nfs server show nfs version 2 as an
allowable service?

-Blake

-----Original Message-----
From: Rene Rivera [mailto:***@redshift-software.com]
Sent: Wednesday, June 22, 2005 10:46 AM
To: ***@openbsd.org
Subject: NFS Protocol not supported when mounting from a Linux machine.

I'm trying to NFS mount from a Linux machine to my new OpenBSD setup and
it just doesn't work. I've run out of things to try, and I keep getting
the "Protocol not supported" error. Trying to force the NFS version:

mount_nfs -2 x.x.x.x:/mnt/export /mnt/export

Doesn't seem to work as the Linux server keeps saying:

svc: unknown version (3)

Any help appreciated.


--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

[Rene Rivera]

Post by Golliher, Blake
Does showmount -e against that nfs server show nfs version 2 as an
allowable service?

Well it shows the mount, I don't see how showmount could be used to tell
if it's v2 or v3. Except perhaps if you mean that if it shows it at all
it's v2:

bash-3.00# showmount -e 192.168.0.3
Exports list on 192.168.0.3:
/export 192.168.0.2

192.168.0.2 is the OBSD box.

Post by Golliher, Blake
Did you try mounting using both tcp and udp?

No. But just did:

bash-3.00# mount_nfs -2 192.168.0.3:/export /mnt/export.3
mount_nfs: /mnt/export.3: Protocol not supported
bash-3.00# mount_nfs -2 -T 192.168.0.3:/export /mnt/export.3
mount_nfs: /mnt/export.3: Protocol not supported
bash-3.00# mount_nfs -2 -U 192.168.0.3:/export /mnt/export.3
mount_nfs: /mnt/export.3: Protocol not supported

Post by Golliher, Blake
Also try using rpcinfo
rpcinfo -u hostname nfs
rpcinfo -u hostname mountd
rpcinfo -t hostname nfs
rpcinfo -t hostname mountd

It all looks OK:

bash-3.00# rpcinfo -u 192.168.0.3 nfs
program 100003 version 2 ready and waiting
bash-3.00# rpcinfo -u 192.168.0.3 mountd
program 100005 version 1 ready and waiting
program 100005 version 2 ready and waiting
program 100005 version 3 ready and waiting
bash-3.00# rpcinfo -t 192.168.0.3 nfs
program 100003 version 2 ready and waiting
bash-3.00# rpcinfo -t 192.168.0.3 mountd
program 100005 version 1 ready and waiting
program 100005 version 2 ready and waiting
program 100005 version 3 ready and waiting


Any other ideas? I'm really lost here, because I've done everything I
thought should be done. And just in case this is the exports on the
Linux machine:

/export 192.168.0.2(rw,no_wdelay,no_subtree_check,sync)

[jared r r spiegel]

Post by Rene Rivera
bash-3.00# mount_nfs -2 192.168.0.3:/export /mnt/export.3
mount_nfs: /mnt/export.3: Protocol not supported
bash-3.00# mount_nfs -2 -T 192.168.0.3:/export /mnt/export.3
mount_nfs: /mnt/export.3: Protocol not supported
bash-3.00# mount_nfs -2 -U 192.168.0.3:/export /mnt/export.3
mount_nfs: /mnt/export.3: Protocol not supported

i checked /usr/src/sbin/mount{,_nfs} and /usr/src/sys/nfs
to see what part of the code is making the 'Protocol not supported',
but didn't find it. :( doing a global search in /usr/src
( granted, if somewhere in the code it is like '%s not supported'
or crosses a terminal line, i would've missed it ):

----
[/usr/src] $ find . -type f | xargs grep "Protocol not supported"
./gnu/lib/libiberty/src/strerror.c: ENTRY(EPROTONOSUPPORT, "EPROTONOSUPPORT", "Protocol not supported"),
./gnu/usr.bin/cvs/lib/strerror.c: ENTRY(EPROTONOSUPPORT, "EPROTONOSUPPORT", "Protocol not supported"),
./gnu/usr.bin/cvs/os2/porttcp.c: case SOCEPROTONOSUPPORT: return "Protocol not supported";
./gnu/usr.bin/cvs/windows-NT/sockerror.c: /* EPROTONOSUPPORT */ "Protocol not supported",
./gnu/usr.bin/perl/pod/perlfaq.pod:Why doesn't my sockets program work under System V (Solaris)? What does the error message "Protocol not supported" mean?
./gnu/usr.bin/perl/pod/perlfaq8.pod:=head2 Why doesn't my sockets program work under System V (Solaris)? What does the error message "Protocol not supported" mean?
./gnu/usr.bin/perl/pod/perltoc.pod:does the error message "Protocol not supported" mean?
./lib/libc/gen/errlist.c: "Protocol not supported", /* 43 - EPROTONOSUPPORT */
./lib/libc/nls/C.msg:43 Protocol not supported
./lib/libc/sys/intro.2:.It Er 43 EPROTONOSUPPORT Em "Protocol not supported" .
./libexec/ftp-proxy/ftp-proxy.c: "522 Protocol not supported, use (1)\r\n");
./libexec/ftp-proxy/ftp-proxy.c: "501 Protocol not supported\r\n");
./libexec/ftpd/ftpd.c: epsv_protounsupp("Protocol not supported");
./libexec/ftpd/ftpd.c: * 522 Protocol not supported (proto,...)
./sys/sys/errno.h:#define EPROTONOSUPPORT 43 /* Protocol not supported */
./usr.sbin/route6d/route6d.c: /* Protocol not supported */
./usr.sbin/route6d/route6d.c: /* Protocol not supported */
----

so that is looking like nothing that has in specific to
to with NFS... <shrug>

on a whim, i tried mounting a remote nfs partition onto
a local dir with a '.' in it, but that worked ok for v2/v3.

Post by Rene Rivera
thought should be done. And just in case this is the exports on the
/export 192.168.0.2(rw,no_wdelay,no_subtree_check,sync)

this probably doesn't matter, but what if you just change the
options to be a simple (rw) or (ro)? perhaps those options
only apply on the server side and are therefore not communicated
over to the 192.168.0.3 client, but .. ?

any chance of making the linux allow nfs v3 and trying that,
if only to see if you get the same error?

jared

-

[ openbsd 3.7 GENERIC ( jun 10 ) // i386 ]

[Ted Unangst]

Post by jared r r spiegel
i checked /usr/src/sbin/mount{,_nfs} and /usr/src/sys/nfs
to see what part of the code is making the 'Protocol not supported',
but didn't find it. :( doing a global search in /usr/src
( granted, if somewhere in the code it is like '%s not supported'
./sys/sys/errno.h:#define EPROTONOSUPPORT 43 /* Protocol not supported */

that's the one. find that in the nfs code.

[Rene Rivera]

Post by jared r r spiegel
this probably doesn't matter, but what if you just change the
options to be a simple (rw) or (ro)? perhaps those options
only apply on the server side and are therefore not communicated
over to the 192.168.0.3 client, but .. ?

Tried it, doesn't help :-(

Post by jared r r spiegel
any chance of making the linux allow nfs v3 and trying that,
if only to see if you get the same error?

I don't know how. There's nothing in the man pages that mentions the nfs
version, so my guess would be v2 is all it can do.

Of course the most frustrating aspect of all this is that neither side
is very informative as to what is going on.

[Jochem Kossen]

Post by Rene Rivera

Post by jared r r spiegel
this probably doesn't matter, but what if you just change the
options to be a simple (rw) or (ro)? perhaps those options
only apply on the server side and are therefore not communicated
over to the 192.168.0.3 client, but .. ?

Tried it, doesn't help :-(

Post by jared r r spiegel
any chance of making the linux allow nfs v3 and trying that,
if only to see if you get the same error?

I don't know how. There's nothing in the man pages that mentions the nfs
version, so my guess would be v2 is all it can do.
Of course the most frustrating aspect of all this is that neither side
is very informative as to what is going on.

have you tried mounting it without the -2 argument?

[Rene Rivera]

Post by Rene Rivera
Of course the most frustrating aspect of all this is that neither side
is very informative as to what is going on.

To reply to those who said look at tcpdump and try and figure out what's
going on...

192.168.0.3: NFS server Linux 2.6
192.168.0.2: NFS client OBSD 3.7

On the server:
15:54:29.996924 IP (tos 0x0, ttl 64, id 39056, offset 0, flags [none],
length: 132) 192.168.0.2.746201734 > 192.168.0.3.2049: 104 getattr [|nfs]
15:54:29.997076 IP (tos 0x0, ttl 64, id 73, offset 0, flags [DF],
length: 60) 192.168.0.3.2049 > 192.168.0.2.746201734: reply ok 32
getattr PROG_MISMATCH
15:54:29.997524 IP (tos 0x0, ttl 64, id 40191, offset 0, flags [none],
length: 84) 192.168.0.2.915 > 192.168.0.3.111: UDP, length: 56
15:54:29.998438 IP (tos 0x0, ttl 64, id 88, offset 0, flags [DF],
length: 56) 192.168.0.3.111 > 192.168.0.2.915: [udp sum ok] UDP, length: 28
15:54:29.998623 IP (tos 0x0, ttl 64, id 61552, offset 0, flags [none],
length: 84) 192.168.0.2.826 > 192.168.0.3.111: UDP, length: 56
15:54:29.998825 IP (tos 0x0, ttl 64, id 89, offset 0, flags [DF],
length: 56) 192.168.0.3.111 > 192.168.0.2.826: [udp sum ok] UDP, length: 28
15:54:29.999031 IP (tos 0x0, ttl 64, id 41765, offset 0, flags [none],
length: 164) 192.168.0.2.730 > 192.168.0.3.919: UDP, length: 136
15:54:30.073386 IP (tos 0x0, ttl 64, id 28, offset 0, flags [DF],
length: 84) 192.168.0.3.919 > 192.168.0.2.730: UDP, length: 56
15:54:30.073546 IP (tos 0x0, ttl 64, id 41411, offset 0, flags [none],
length: 132) 192.168.0.2.746201775 > 192.168.0.3.2049: 104 getattr [|nfs]
15:54:30.073703 IP (tos 0x0, ttl 64, id 74, offset 0, flags [DF],
length: 60) 192.168.0.3.2049 > 192.168.0.2.746201775: reply ok 32
getattr PROG_MISMATCH

And on the client:

10:54:29.993447 192.168.0.2.1009 > 192.168.0.3.2049: xid 0x2c7a2286 104
getattr [|nfs] (ttl 64, id 39056, len 132)
10:54:29.993712 192.168.0.3.2049 > 192.168.0.2.1009: xid 0x2c7a2286
reply ok 32 getattr PROG_MISMATCH (DF) (ttl 64, id 73, len 60)
10:54:29.994060 192.168.0.2.915 > 192.168.0.3.111: udp 56 (ttl 64, id
40191, len 84)
10:54:29.995069 192.168.0.3.111 > 192.168.0.2.915: [udp sum ok] udp 28
(DF) (ttl 64, id 88, len 56)
10:54:29.995155 192.168.0.2.826 > 192.168.0.3.111: udp 56 (ttl 64, id
61552, len 84)
10:54:29.995454 192.168.0.3.111 > 192.168.0.2.826: [udp sum ok] udp 28
(DF) (ttl 64, id 89, len 56)
10:54:29.995555 192.168.0.2.730 > 192.168.0.3.919: udp 136 (ttl 64, id
41765, len 164)
10:54:30.070035 192.168.0.3.919 > 192.168.0.2.730: udp 56 (DF) (ttl 64,
id 28, len 84)
10:54:30.070082 192.168.0.2.1009 > 192.168.0.3.2049: xid 0x2c7a22af 104
getattr [|nfs] (ttl 64, id 41411, len 132)
10:54:30.070337 192.168.0.3.2049 > 192.168.0.2.1009: xid 0x2c7a22af
reply ok 32 getattr PROG_MISMATCH (DF) (ttl 64, id 74, len 60)

And nothing else. The PROG_MISMATCH seem to match the "unknown version"
messages I see in the server log:

Jun 23 15:54:29 red5of5 kernel: svc: unknown version (3)
Jun 23 15:54:30 red5of5 rpc.mountd: authenticated mount request from
192.168.0.2:730 for /export (/export)
Jun 23 15:54:30 red5of5 kernel: svc: unknown version (3)

And nothing in the OSBD deamon log. Is there some way to configure the
client NFS support to be more verbose?

[Rene Rivera]

Post by Rene Rivera
Of course the most frustrating aspect of all this is that neither side
is very informative as to what is going on.

OK I have no clue how this happened but the mount seems to be working
now. And not only that it's working with the original set of NFS options
I used. Only difference was that I rebooted the OBSD machine. But
strangely it wasn't the first time I rebooted the machine.

Anyway thanks to all for the investigative suggestions.

I'm sure I'll have more questions when I get to the VPN setup in some
not too distant future ;-)

[s***@jpberlin.de]

Post by Rene Rivera

Post by Rene Rivera
Of course the most frustrating aspect of all this is that neither side
is very informative as to what is going on.

OK I have no clue how this happened but the mount seems to be working
now. And not only that it's working with the original set of NFS options
I used. Only difference was that I rebooted the OBSD machine. But
strangely it wasn't the first time I rebooted the machine.
Anyway thanks to all for the investigative suggestions.
I'm sure I'll have more questions when I get to the VPN setup in some
not too distant future ;-)

Just be warned:
If the NFS-Server crashs or reboots and you try to umount the nfs from the
OpenBSD-Box your BSD will risk a Kernel-Panic and data-loss.

I crashed my AMD64 and my Notebook (and some i386 Hardware wich is not my)
this way (and it's reproduceable). :-)

But if you don't do a umount of e.g. /mnt/nfs after the NFS-Server
crashed/powered_off you wont have any trouble.
And if you don't do a `cd /mnt/nfs` after the NFS-Server crashed/powered
off you don't even lose your TTY! ;-)

But "if" you do it you risk again a Kernel-Panic and lose the TTY you're
logged in and "halt -p" should drop you into the ddb-Console where you can
play "hangman".... :-)

Kind regards,
Sebastian