The best practice for NFS home directories


is there a common standard for Fedora where to locate the NFS home directories? In Solaris it used to be /export/home. I cannot export and mount the whole /home directory, since it contains also local account. I first do do not want some local accounts home directories be exported and second I do not want some client’s local home directories overlayed.

Once there is some common standard it would be easy to define selinux policy for that parallel homedir structure. Nowadays I suffer some difficulties regarding selinux and probable bugs in selinux which would be easily came over by having such structure and having stock selinux policy for such structure.



I’m not sure but I think a good place to start might be at How to configure NFS mounts as a user's home directory - Red Hat Customer Portal

Well, the access to the referenced page is protected.


Okay, didn’t realize. How about this File sharing with NFS – Installation :: Fedora Docs Staging or possibly this File sharing with NFS – Administration using Cockpit :: Fedora Docs Staging

Well, there was probabaly some misunderstanding. I am aware of a way, how to export filesystem and how to mount it. I am wondering if there exists some standard path where NFS home directories are expected to be. I would need some common agreement across community. This is due to the need of standard stock selinux filesystem labeling. I do not want a directory at my will. I have it like this now and I experience problems with selinux.


This should be a reasonable option:

sudo semanage fcontext -a -e /home /var/home

Something similar is probably used in Silverblue.

This is solution for the server for example. But when you run fixfiles on the client who does not have the policy configured or you have malicious client, he is able to relabel. This is why I would like to have stock policy with nfs home directories. It will not help against malisious clients but at least not configured ones would be solved.

Maybe /srv/nfs :thinking:

What SELinux labels would they get? Were you planning on relableing them?


system_u:object_r:nfs_file_t or user_u:<user_role>_t depending on your preference.

1 Like

There are no preconfigured SELinux labels for alternative home locations, see:

sudo semanage fcontext -l | grep -e "user_home_t" -e "\s/home"

You should create own path equivalent as explained above.
It can be provisioned to the clients with something like Ansible.

1 Like

The need is to have same path on the server and on the client. Home directory is read from ldap on server and on the client. Is /srv/nfs/home suitable then?

regarding selinux:

semanage fcontext -l | grep /srv

/srv all files system_u:object_r:var_t:s0

This would relabel all the home directories to var_t on the client.

It is not feasible to add labels on all the clients if it is not the default stock policy.


This means your infrastructure does not support what you want to achieve.
Configuration management must be deployed before setting up homes on NFS.
Otherwise you are limited to SELinux defaults and unable to provide an alternative home location, or have to abandon the idea with local users.

1 Like

With respect to SELinux and nfs file system, may give some more information. It says

SELinux offers additional security by locking down the capabilities of services provided in Red Hat Enterprise Linux. By default, NFS mounts have the SELinux context nfs_t, independent of the SELinux context they have on the server that provides the export.


The NFS server can be forced to properly export the SELinux context of a share by switching to NFS version 4.2. This specification currently only exists as an Internet draft. It is already implemented in the NFS server shipped by CentOS/RHEL 7 but needs to be turned on explicitly.

This still doesn’t answer the question about the standard location for exported home directories. I suspect no standard were ever formulated.

Hello Villy,

this is quite old information. In the past the client has seen all the nfs mount as nfs_t. these times everything was working OK, only server managed the contexts. But nowadays the client sees the labels and is able to relabel. Unfortunately, it seems to be a bug, you are allowed to relabel also files I think you should not be able to relabel. when you are root on a client and have mounted the share exported with root_squash, you normally have permissions as some guest user (uid 65534 or similar). But you are able to relabel all the files you have read permissions to. I am trying to achieve situation when nfs home directories are labeled by stock policy. But this needs an agreement on the community to have such path and also the selinux policy administrators to agree to set the policy on it. I do not know how to proceed. Is there some comitee sho can decide the standard path? Or is not it already in the Linux filesystem hierarchy standard?




it seems the only viable solution is to follow Vladislav’s suggestion with semanage and asking all the local admins to apply the command to kindly stopping relabeling server files. I found no way to standardize the nfs homedir localtion and also no response on the bug report. I thought that security is a priority.

Thanks for suggestions


Well, I did give you a context and a location for this to be standardized in your environment. It’s how I or my team would have handled it when I was doing such things years ago.

The fact is to reiterate, there is no standard way. Logic would say if the context exist already for one, use it as “good practice”.


regarding the security is a priority I meant the probable selinu bug I am suffering. The client root is able to relabel any files on the NFS filesystem he is able to list even if the NFS share is exported with root_squash. Sorry I was not explicit on this.



Gotcha :exclamation: That is a very different question IMO. Gimme some minutes here to get back to you. I need to swim through some notes.


Configure user mapping on the NFS server.

Maybe, On the NFS share map the clients root to an unprivileged user.

  • Edit the /etc/exports file and add the all_squash option along with the user mapping option.
  1. Maybe a poor example : /path/to/share *(rw,sync,all_squash,user_squash)
  2. Define the user mapping using the rpc_user option. Here, map the client’s root (UID 0) to a specific unprivileged user (e.g., nfsuser ) on the server,
    /path/to/share *(rw,sync,all_squash,user_squash,root_squash="nfsuser")
    Important: Create the nfsuser user beforehand and set appropriate permissions.
  • Restart the NFS service:

sudo systemctl restart nfs-kernel-server

Let me know what you think here. If you need more help in understanding I can talk some more about this. It ahs been some time since I used such tooling, but maybe I still remember some things. . .

Consider relabeling the NFS share with SELinux.

Futire Edit :

  • I actually found 2 more VERY LONG notes on this or similar topic. 1 is a wholey SELINux solution that is very involved. The other is similar to this. one where the client/root is remapped to an unprivlaged user on the NFS server.