Re: NFSv4: Invalid fstype: Invalid argument
- In reply to: FreeBSD User : "NFSv4: Invalid fstype: Invalid argument"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 03 Jul 2022 10:58:55 UTC
Am Sun, 3 Jul 2022 11:57:33 +0200 FreeBSD User <freebsd@walstatt-de.de> schrieb: Sorry for the noise, the learning process is still in progress and I learned about the until-now-not-fully-understood V4: entry in /etc/exports. Thanks for reading and patience. regards, oh > 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