Date: Sun, 3 Jul 2022 11:57:33 +0200 From: FreeBSD User <freebsd@walstatt-de.de> To: FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: NFSv4: Invalid fstype: Invalid argument Message-ID: <20220703115800.5e150d95@thor.intern.walstatt.dynvpn.de>
next in thread | raw e-mail | index | archive | help
Hello folks,
Trying to mount a NFS filesystem offered by a FreeBSD 12.3-p5 (XigmaNAS) from a recent CURRENT
(FreeBSD 14.0-CURRENT #19 main-n256512-ef86876b846: Sat Jul 2 23:31:53 CEST 2022 amd64) via
:/etc # mount -t nfs -o vers=4 192.168.0.11:/mnt/NAS00/home /tmp/mnt
results in
mount_nfs: nmount: /tmp/mnt, Invalid fstype: Invalid argument
and checking whether I can mount NFSv3 (I have explicitely set NFSv4 only on the server side,
see below) via
:/etc # mount -t nfs -o vers=3,mntudp 192.168.0.11:/mnt/NAS00/home /tmp/mnt
[udp] 192.168.0.11:/mnt/NAS00/home: RPCPROG_NFS: RPC: Program not registered
or
:/etc # mount -t nfs -o vers=3,mntudp [fd01:a37::11]:/mnt/NAS00/home /tmp/mnt
[udp6] fd01:a37::11:/mnt/NAS00/home: RPCPROG_NFS: RPC: Program not registered
Womdering about the TCP conenction attempts, I checked the configurations on both, the CURRENT
and XigmaNAS (server) side.
[... server side ...]
nas01: ~# ps -waux|grep mountd
root 4332 0.0 0.0 11684 2652 - Is 23:13 0:00.01 /usr/sbin/mountd -l -r -S
-R /etc/exports /etc/zfs/exports
rpcinfo -p
program vers proto port service
100000 4 tcp 111 rpcbind
100000 3 tcp 111 rpcbind
100000 2 tcp 111 rpcbind
100000 4 udp 111 rpcbind
100000 3 udp 111 rpcbind
100000 2 udp 111 rpcbind
100000 4 local 111 rpcbind
100000 3 local 111 rpcbind
100000 2 local 111 rpcbind
100024 1 udp 671 status
100024 1 tcp 671 status
100021 0 udp 1003 nlockmgr
100021 0 tcp 603 nlockmgr
100021 1 udp 1003 nlockmgr
100021 1 tcp 603 nlockmgr
100021 3 udp 1003 nlockmgr
100021 3 tcp 603 nlockmgr
100021 4 udp 1003 nlockmgr
100021 4 tcp 603 nlockmgr
I do not see mountd nor nfsd being registered, hope this is all right within a NFSv4-only
environment.
Well, on the CURRENT server that provides without flaws NFSv4 for the CURRENT client I try to
access the XigmaNAS NFSv4 fs from, rpcinfo looks like:
(current server):
root@walhall:/usr/src # rpcinfo -p
program vers proto port service
100000 4 tcp 111 rpcbind
100000 3 tcp 111 rpcbind
100000 2 tcp 111 rpcbind
100000 4 udp 111 rpcbind
100000 3 udp 111 rpcbind
100000 2 udp 111 rpcbind
100000 4 local 111 rpcbind
100000 3 local 111 rpcbind
100000 2 local 111 rpcbind
100024 1 udp 774 status
100024 1 tcp 774 status
100021 0 udp 746 nlockmgr
100021 0 tcp 661 nlockmgr
100021 1 udp 746 nlockmgr
100021 1 tcp 661 nlockmgr
100021 3 udp 746 nlockmgr
100021 3 tcp 661 nlockmgr
100021 4 udp 746 nlockmgr
100021 4 tcp 661 nlockmgr
Well, I also checked from client to current server and client to XigmaNAS server via rpcinfo
-p and I get always the very same result.
Checking the accessibility of the server host on the net via nmap gives this result (please be
aware we use a dual stack network and need both IPv6 and IPv4 access so this attempt shows
IPv4 access, but IPv6 access is also granted and assured):
UDP:
:/etc # nmap -sU 192.168.0.11
Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-03 11:05 CEST
Nmap scan report for nas01.intern (192.168.0.11)
Host is up (0.00094s latency).
Not shown: 996 closed ports
PORT STATE SERVICE
111/udp open rpcbind
514/udp open|filtered syslog
2049/udp open nfs
5353/udp open zeroconf
and TCP (since port 2049/NFSv4 is tcp):
:/etc # nmap -sS 192.168.0.11
Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-03 11:34 CEST
Nmap scan report for nas01.intern (192.168.0.11)
Host is up (0.00074s latency).
Not shown: 996 closed ports
PORT STATE SERVICE
22/tcp open ssh
111/tcp open rpcbind
443/tcp open https
2049/tcp open nfs
I'm out of ideas here. What does
mount_nfs: nmount: /tmp/mnt, Invalid fstype: Invalid argument
mean? Is it the server reporting that it doesn't serve the requested fstyp or is there an
issue with the local filesystem/mountpoint (located on UFS/FFS, the backend NFS fs are all
located on ZFS)?
I'm drifting like a dead man in the water here and I did not find aome answeres to the error
reported here in the net applicable to the problem seen.
Some hints are highly appreciated.
Tahnks in advance and kind regards,
oh
--
O. Hartmann
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220703115800.5e150d95>