Discussion:
[Bug 284939] NFSv4 server and clients.
Add Reply
b***@freebsd.org
2025-02-21 01:30:37 UTC
Reply
Permalink
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284939

Vladimir Druzenko <***@FreeBSD.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@FreeBSD.org
Assignee|***@FreeBSD.org |***@FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
b***@freebsd.org
2025-02-21 02:29:09 UTC
Reply
Permalink
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284939

Rick Macklem <***@FreeBSD.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@FreeBSD.org

--- Comment #1 from Rick Macklem <***@FreeBSD.org> ---
(In reply to eu9gu4 from comment #0)
No name and/or group mapping for uid,gid:(0:0)

The above line indicates that username/uid mapping
is not configured correctly.
(This might be visible by just doing "ls -l" on an
NFSv4 mount and seeing "nobody" or "nogroup".)

It's confusing. There are two ways it can be configured.
1 - Put the uid/gid #s in the strings. This works for
AUTH_SYS, but not Kerberized mounts.
To do this, on both the client and server you must put
the following in /etc/sysctl.conf:
vfs.nfs.enable_uidtostring=1
and on the server you also need
vfs.nfsd.enable_stringtouid=1
--> For this case, nfsuserd must not be running and if it
has been running, the machine must be rebooted to forget
about it.
(uid/gids in strings is the default for Linux.)

OR

Do not set either of the sysctls mentioned above and
run nfsuserd on all FreeBSD clients and servers.
You may need to use the -domain <my.domain> option
on nfsuserd to make sure all the machines use the same domain.
(If all your systems have a fqdn for hostname and they all
have the same domain, then the "-domain" is not needed.)
--> This configuration must ne used for Kerberized mounts.
(I think "man nfsv4" tries to explain this.)
To do this under Linux, you need to run rpc.idmapd.

Like it or not, the RFC authors for NFSv4 made it
"less posix centric", which included specifying users
and groups via "***@domain" and "***@domain" instead
of uid/gid values. (The uid/gids in strings is a cheat
to simplify this, so uid 1001 becomes "1001", as an example.
When this cheat was first done, it was for testing only, but
Linux adopted it, in part to support NFSv4 root file systems
and since they are the dominant system, they got away with it.
--
You are receiving this mail because:
You are the assignee for the bug.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
b***@freebsd.org
2025-02-21 02:46:51 UTC
Reply
Permalink
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284939

Mark Linimon <***@FreeBSD.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Summary|NFSv4 server and clients. |NFSv4 server and clients:
| |why can't a NFSv4 server on
| |FreeBSD work with a NFSv4
| |client?
--
You are receiving this mail because:
You are the assignee for the bug.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
b***@freebsd.org
2025-02-21 03:26:55 UTC
Reply
Permalink
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284939

--- Comment #2 from ***@gmail.com ---
(In reply to Rick Macklem from comment #1)

First I used your option 2: BSD v4 client works with BSD v4 server, but Linux
v4 client does not.

Then I added your option 1: both Linux and BSD v4 clients work with BSD v4
server.

Thanks Rick! Problem solved, the bug should be closed.

However, this is not mentioned in the handbook and it should be.
--
You are receiving this mail because:
You are the assignee for the bug.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...