Issue with NFSv4

[Fabrizio Pirovano]

We are testing NFSv4 on a coldfire mcf5329 platform using rtems-6 (MASTER) and 6-freebsd-12 (downloaded September 9th).
The tool chain is bould by rtems-source-builder last version.

The test program testsuite/nfs01 work correctly but if we try to copy a file in a subfolder of NFS disk we meet the issue that I try to describe below:

using telnetd01 example from the testsuite (adding NFS filesytem at configuration with #define CONFIGURE_FILESYSTEM_NFS) and opening a shell
we are capable to mount a NFS disk with the command:

mount -t nfs -o nfsv4,minorversion=1 192.168.3.36:/rtems /nfs

(where "192.168.3.36/rtems" is a share from an ubuntu 20.1 machine).

Mount is fine and we receive the following reply

"nfs: mount: nfs -> 192.168.3.36:/rtems (nfsv4,minorversion=1)
nfs: mount args: 8

16 addr=10 02 08 01 ffffffc0 ffffffa8 03 24 00 00 00 00 00 00 00 00

0 nfsv4
7 dirpath=/rtems
4 fstype=nfs
4 fspath=nfs

20 hostname=192.168.3.36:/rtems

0 rw
2 minorversion=1

nfs: mount: (0) Success"

The issue happen when we try to copy a file in a /nfs subfolder.
If we create subfolders

mkdir /nfs/1
mkdir /nfs/1/2
mkdir /nfs/1/2/3
folders are creted correctly but if we try to copy a file as:

cp xxx /nfs/1/2/3

unfortunately the file xxx is copied in /nfs/1/2 and NOT inside /nfs/1/2/3 folder.
The same issue happen in other locations:

cp xxx /nfs/1/2 file is copied in /nfs/1
cp xxx /nfs/1 file is copied in /nfs

[Fabrizio Pirovano]

Hi Chris, No news about this issue? we are developing a project based on NFS and rtems but we are
stopped. There is any prevision about a solution ?
Thanks in advance.

[Chris Johns]

Replying to Fabrizio Pirovano:

Hi Chris, No news about this issue? we are developing a project based on NFS and rtems but we are stopped. There is any prevision about a solution ?

I am sorry about the delay and I am sorry your project has stopped. I have been busy on a few other things but I plan to take a look.

[kgardas]

Fabrizio,

let me ask, are you sure you are using NFSv4 and not plain old NFSv2 on the RTEMS side? I'm asking since all evidence I've seen so far point to only NFSv2 on the RTEMS and that is including wireshark debugging.

The idea: your -o options get silently ignored, your RTEMS is using NFSv2 which your server luckily supports although there are some issues...

By any chance, if you are using Linux as a NFS server, what does:

$ sudo cat /proc/fs/nfsd/versions

tells you?

Example: Ubuntu 20.04 LTS as a NFS server by default:

-2 +3 +4 +4.1 +4.2

and obviously RTEMS refuses to work with that. E.g. nfs01.exe:

NFS (proc 0) - RPC: Program/version mismatch
NFS Ping 169.254.1.1  failed: I/O error

but when I reconfigure and enforce NFSv2 to be supported, then cat tells correctly:

+2 +3 +4 +4.1 +4.2

and RTEMS nfs01.exe runs fine.

Now, back to your testcase as I'm able to test that too now. Actually with few days old RTEMS and libbsd repos, both master branches I'm not able to duplicate your issue. See:

SHLL [/nfs] # ls -la /nfs/1/2/3              
total 2
drwxr-xr-x  2 1000  100  2 Feb  1  2023 .
drwxr-xr-x  3 1000  100  4 Feb  1  2023 ..
SHLL [/nfs] # cp rtems.txt /nfs/1/2/3
SHLL [/nfs] # ls -la /nfs/1/2/3                    
total 3
drwxr-xr-x  2 1000  100   3 Feb  1  2023 .
drwxr-xr-x  3 1000  100   4 Feb  1  2023 ..
-rw-r--r--  1 1000  100  38 Feb  1  2023 rtems.txt

perhaps the issue is already solved?

[Joel Sherrill]

Which version of RTEMS are you using and which network stack?

NFS v4 is only in libbsd

[kgardas]

Oh. Today, as of February 1 2023, I followed README from libbsd: ​https://github.com/RTEMS/rtems-libbsd -- concretely steps to make that working on zynq-a9-qemu bsp. When I did so, then compiled nsf01.exe was purely NFS v2 client application.

I just passed in custom network configuration to be more in-line with recommended qtap configuration:

NET_CFG_SELF_IP = 169.254.10.10
NET_CFG_NETMASK = 255.255.0.0
NET_CFG_PEER_IP = 169.254.1.1
NET_CFG_GATEWAY_IP = 169.254.1.1

Let me ask, where exactly is this NFS v4 implementation located? Thanks!

[Fabrizio Pirovano]

Hi Karel,
as I wrote in my opened ticket NFSv4 implementation is located in 6-freebsd-12 branch.

my Ubuntu server when I type sudo cat /proc/fs/nfsd/versions answer -2 +3 +4 +4.1 +4.2
so I am sure that I am not using NFSv2 also because I forced rtems side to use NFSV4.1
and wireshark dump confirm NFSv4.

[kgardas]

Hi Fabrizio,

cool! I stand corrected then and it looks like NFSv4 got into the 6-freebsd-12 and not to the master. What a confusion! I really would expect everything to be on the master as it is described as a:

master

This branch is intended for the RTEMS master which tracks the FreeBSD master branch. This branch must be used for libbsd development. Back ports to the 6-freebsd-12 are allowed.

sorry about my confusing message than, it was not done on purpose. I was confused myself. :-)

[Fabrizio Pirovano]

Hi Karel,
Do you have news? You were capable to reproduce the issue and confirm it ?
Tell me if I can support you in any way.
BR

[Chris Johns <chrisj@…>]

In 60e40e9/rtems-libbsd:

freenbsd/vfs: VFS attributes need to have the same size mode_t variable

If the size in the attributes struct does not match the mode_t the
VNOVAL checks fail because size of the values are not the same.

Updates #4723

[Chris Johns <chrisj@…>]

In 65913f4/rtems-libbsd:

syscall/open: Reference the path info directory vnode

The kernel open call requires a path so to open a file we need to
set the current directory to the parent vnode. If the open mode is
create the path info vnode is the directory to perform the open
create in. Using the parent node creates the file in wrong path.

Updates #4723

[Chris Johns <chrisj@…>]

In 1dfdee9/rtems-libbsd:

freebsd/vfs: Pass in the td's cred to the VFS calls

Closes #4723