Bug 1228349 (cockpit_config_nfs_v4) - [RFE] Add functionality for configuring NFSv4 clients
Summary: [RFE] Add functionality for configuring NFSv4 clients
Alias: cockpit_config_nfs_v4
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: cockpit
Version: 8.1
Hardware: Unspecified
OS: Unspecified
Target Milestone: pre-dev-freeze
: ---
Assignee: Martin Pitt
QA Contact: Release Test Team
Vendula Ferschmannova
URL: https://trello.com/c/PZPciouD/146-nfs...
Depends On:
Blocks: node-cockpit ovirt-node-ng-platform 1477926 1656582 ovirt-node-ng-44-el81-platform
TreeView+ depends on / blocked
Reported: 2015-06-04 17:33 UTC by Ryan Barry
Modified: 2021-07-10 13:59 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
: 1228351 (view as bug list)
Last Closed: 2019-12-16 08:18:54 UTC
Type: Bug
Target Upstream Version:

Attachments (Terms of Use)

Description Ryan Barry 2015-06-04 17:33:47 UTC
Description of problem:
Cockpit does not provide a way to configure any aspects of NFS configuration.

There should be a way to set the NFSv4 domain. 

Not required by this RFE but nice to have:

Mounting remote filesystems.
Exporting filesystems.

This should be a high level API which takes care to perform the necessary platform tasks (service restarts if needed).

Comment 1 Fabian Deutsch 2015-11-30 15:53:58 UTC
Can we somehow raise the priority of this item?

Comment 2 Fedora Admin XMLRPC Client 2016-10-20 12:10:33 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 3 Fabian Deutsch 2016-12-13 09:08:39 UTC
Also tracked in upstream trello: https://trello.com/c/PZPciouD/146-nfs-client-configuration

Comment 12 Andreas Nilsson 2017-07-12 19:43:48 UTC
I've created a wiki page for this feature here:

Comment 16 Marius Vollmer 2017-07-17 07:25:20 UTC
(In reply to Ryan Barry from comment #0)
> Description of problem:
> Cockpit does not provide a way to configure any aspects of NFS configuration.
> There should be a way to set the NFSv4 domain. 

Let's start with setting the NFSv4 domain.

I don't know what a NFSv4 domain is.  Can you point to some documentation?

How do you set the NFSv4 domain without Cockpit?

Comment 17 Ryan Barry 2017-07-17 11:37:34 UTC
It's used for kerberized NFSv4.

See https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/ch-nfs.html

We set it in the past by directly setting values in the file.

Comment 18 Marius Vollmer 2017-07-20 10:59:01 UTC
> We set it in the past by directly setting values in the file.

Sorry, I, dumb.  Which file, what values?

Can you show a concrete shell/vi session that you would like to be replaced with clicking buttons in Cockpit?

Comment 19 Ryan Barry 2017-07-31 12:32:15 UTC
Literally only "domain" in /etc/idmapd.conf

Comment 20 Marius Vollmer 2017-08-14 07:47:44 UTC
(In reply to Ryan Barry from comment #19)
> Literally only "domain" in /etc/idmapd.conf


Comment 23 Martin Pitt 2018-03-26 16:01:43 UTC
So what's left here is setting the NFS 4 domain in /etc/idmapd.conf; the NFS client functionality for adding transient or permanent NFS mounts has existed for a while.

I experimented a bit with domain and ID mapping. On the server and client I added this to idmapd.conf:

Method = static
Domain = cockpit.lan

joe = joe

On the server, "joe" has uid 1002, on the client it has uid 1001. With just that, of the file on the client always appears to have uid:gid 1002:1002, i. e. is not mapped to the local "joe" user.

But when disabling the disabling (yay how confusing) of idmapping on the server with

    echo N > /sys/module/nfsd/parameters/nfs4_disable_idmapping
    systemctl restart nfs-idmapd

it works [2], i. e. the file now appears to belong to the local "joe" user.  However, this is *independent* of the Domain= setting on the client, I can also set it to "Domain = foo" or leave it undefined, and it still works.

So it appears to me without a kerberos setup, that Domain= is completely irrelevant, and there is no way to demonstrate/test the NFS domain usage.

But with IPA/kerberos, what is the use case for setting a domain there? Wouldn't/shouldn't that always be the kerberos realm? What is the use case of having the NFS idmap domain be different from the kerberos one, if all the "global" user names are qualified by the krb domain anyway?

I. e. I'm still struggling with an actual use case / demonstration / detailed reproducer here. The documentation (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-nfs and man idmapd.conf) say "domain must be the same on client and server", but don't give any details, and as shown above I don't see why a user would actually change this, and how to explain this in the UI.

[1] https://serverfault.com/questions/812813/nfsv4-user-mapping
[2] https://serverfault.com/questions/514118/mapping-uid-and-gid-of-local-user-to-the-mounted-nfs-share/

Comment 27 Sandro Bonazzola 2018-11-28 10:54:49 UTC
Bug was acked for 7.5 but missed 7.5 (and 7.6).
Can we get a target mileston for having this bug fixed? 7.6.z? 7.7?

Comment 28 Martin Pitt 2018-11-29 07:25:44 UTC
There is no target release yet, as the issue hasn't been well-defined yet. See comment #23. Before we can actually replicate the problem, we can't start on a solution.

Comment 29 Sandro Bonazzola 2019-06-14 07:35:16 UTC
Not included in 7.7, retrying with 8.1 for RHV 4.4

Comment 30 Martin Pitt 2019-06-14 11:07:50 UTC
Setting back needsinfo, see https://bugzilla.redhat.com/show_bug.cgi?id=1228349#c23 -- it's still totally unclear to me what exactly is being asked here and how to test it.

Comment 31 Sandro Bonazzola 2019-10-11 13:10:01 UTC
Adding needinfo on Yuval

Comment 32 Yuval Turgeman 2019-10-22 11:44:42 UTC
Sorry, I'm not sure I understand this as well, adding Ryan

Comment 33 Ryan Barry 2019-10-22 13:01:29 UTC
We pretty much rely on this being handled by platform. That said, this is a very old RFE originally opened to get RHVH 4.x on feature parity with 3.x (and even there, the only QE was checking that the values were set). With no tickets in years, I'd suggest closing

Comment 34 Sandro Bonazzola 2019-12-16 08:18:54 UTC
According to comment #33 closing this with resolution wontfix.

Note You need to log in before you can comment on or make changes to this bug.