Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 3 Jul 2022 12:58:55 +0200
From:      FreeBSD User <freebsd@walstatt-de.de>
To:        FreeBSD CURRENT <freebsd-current@freebsd.org>
Subject:   Re: NFSv4: Invalid fstype: Invalid argument
Message-ID:  <20220703125922.2d9b2b34@thor.intern.walstatt.dynvpn.de>
In-Reply-To: <20220703115800.5e150d95@thor.intern.walstatt.dynvpn.de>
References:  <20220703115800.5e150d95@thor.intern.walstatt.dynvpn.de>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220703125922.2d9b2b34>