[RTEMS Project] #4723: Issue with NFSv4
RTEMS trac
trac at rtems.org
Wed Feb 1 18:23:47 UTC 2023
#4723: Issue with NFSv4
-------------------------------+--------------------------
Reporter: Fabrizio Pirovano | Owner: Chris Johns
Type: defect | Status: accepted
Priority: high | Milestone:
Component: fs | Version: 6
Severity: normal | Resolution:
Keywords: | Blocked By:
Blocking: |
-------------------------------+--------------------------
Comment (by 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?
--
Ticket URL: <http://devel.rtems.org/ticket/4723#comment:4>
RTEMS Project <http://www.rtems.org/>
RTEMS Project
More information about the bugs
mailing list