Home On Nfs

Home » CentOS » Home On Nfs
CentOS 19 Comments


I have the home directory of a user on an nfs server and mount it on a client. When the user logs in, they end up in the root directory rather than in their actual home directory and need to cd into it.

The user can read and write to their home directory, so it kinda works fine — but only kinda. When the user starts emacs, some of the settings in ~/.emacs are not applied, but the saved desktop is being loaded.

Both machines are running CentOS 7.4. What could be wrong with the nfs mount?

19 thoughts on - Home On Nfs

  • hw wrote:
    1. Do you have /etc/auto.master set up? How about /etc/auto.home (or do you set that in auto.master)? Is /etc/exports on the NFS server exporting correctly (/home server:/exported/homes/&)?
    2. Is autofs enabled and running on the client?


  • Are you using kerberos with NFS4 with security set to krb5?
    Your description sounds as if the user cannot really get to the mount….

  • There are seven fields on each line in a typical Linux “/etc/passwd” file.

    For a line that looks like this:

    1. root: Account username.
    2. x: Placeholder for password information. The password is obtained from the “/etc/shadow” file.
    3. 0: User ID. Each user has a unique ID that identifies them on the system. The root user is always referenced by user ID 0.
    4. 0: Group ID. Each group has a unique group ID. Each user has a “primary”
    group that is used as the group by default. Again, the root group’s ID is always 0.
    5. root: Comment field. This field can be used to describe the user or user’s function. This can be anything from contact information for the user, to descriptions of the service the account was made for.
    6. /root: Home directory. For regular users, this would usually be
    “/home/username”. For root, this is “/root”.
    7. /bin/bash: User shell. This field contains the shell that will be spawned or the command that will be run when the user logs in.

    I would take a look at that user’s line in /etc/passwd and see what their home directory is set to.


  • m.roth@5-cent.us writes:

    No, the directory is mounted via an entry in /etc/fstab.

    The directory itself is exported, like

    /path/to/mountpoint/user client(rw)

    No, do have to do it that way?

    This is only one user and one client, so I didn´t see any need to bother with automatic mounting. It´s automatic anyway because of the fstab entry.

    “Didn’t work” is an error.

  • Louis Lagendijk writes:

    Kerberos is not involved.

    Yes, but the user can. Just enter cd in a shell, and he´s in his home directory where he should end up to begin with.

    “Didn’t work” is an error.

  • John Hodrien writes:

    It does. The user existed before the directory was (i. e. the very disks were) moved to the server, and it´s now mounted in the same place as before on the client.

    “Didn’t work” is an error.

  • Cameron Smith writes:

    The user is set up correctly. Nothing changed other than that the disks holding the directory are now in the server rather than in the client, exported from the server via nfs and mounted through an fstab entry on the client.

    I´m using this right now, and it works fine other than the user not ending up in the home directory and emacs not applying everything from

    As far as I can tell, what is not applied is

    ;; custom-set-faces was added by Custom.
    ;; If you edit it by hand, you could mess it up, so be careful.
    ;; Your init file should contain only one such instance.
    ;; If there is more than one, they won’t work right.
    ‘(default ((t (:inherit nil :stipple nil :background “black” :foreground “green” :inverse-video nil :box nil :strike-through nil :overline nil :underline nil :slant normal :weight normal :height 78 :width normal :foundry “unknown” :family “DejaVu Sans Mono”)))))

    which is the second last line in ~/.emacs. Perhaps there´s more which is not applied without me noticing yet. However, there could be another reason for that; I´ll have to figure that out later.

    “Didn’t work” is an error.

  • Sounds like you haven’t set the selinux Boolean for NFS homedirs. setsebool -P use_nfs_home_dirs 1

    Jonathan Billings

  • Jonathan Billings writes:

    Oh, indeed, I didn´t know that I need to do that.

    Do I do this on the client or on the server or both?

    “Didn’t work” is an error.

  • If you find that the problem comes back in the near future (or perhaps check as a preventative), you should look to see if the client machine is using the ‘soft’ mount option instead of ‘hard,intr’ on the home dirs. A few years ago it took me better than a month to figure out that some other admin had (on some machines) thought that using soft would cause less waiting on reboots, but we found that the side effect on home directories was corrupt data and strange issues on user login. (soft can work OK if there is a longish timeout between mount request and mount use, but if it is quick like autofs at login, then soft falls down.)

  • An alternative (quite possibly less mature) is to export the nfs mount with “security_level” and make sure to mount with version 4.2.

    This will instead make NFS handle the security contexts and allow the nfs mount to work as any other selinux compatible file system.

    Afaict this should work on 7.4 but I’ve only ever tried it on Fedora.


  • hw a écrit :
    About NFS home directories and CentOS have you .nfsxxxxxxxxx tempory files located in the home of your user ?
    I have this very often. I was not able to found any documentation about this but if they are temporary files for NFS transactions is there a way to store them on on local client disk area like /tmp instead of a NFS
    These files are some time difficult (if not impossible) to remove by the user on the client side and stay on the disk… until I remove the oldest ones on the server side.


  • It’s not difficult to find out what the files are! They are a kludge on the behalf of NFS to mimic the way a native filesystem doesn’t free blocks until all file handles are closed, even if the file is deleted. So, if a file is deleted and there are still file handles that reference it, the file is renamed to .nfsxxxxxxxx until the handle is closed. (Even the NFS devs think it’s a kludge – the feature is called
    ‘silly rename’ in the code. http://nfs.sourceforge.net/#faq_d2 )

    They can’t be anywhere else (like on /tmp) because they *are* on the nfs filesystem.

    If you remove one of the files on the client, and there is still an open filehandle, the file is re-created with a different name, because, well, there’s still an open file handle associated with those blocks of data.

    If you delete one of those files on the server side, and there are still open handles on the client side associated with it then NFS
    corruption and app crashing will ensue.

    The way to deal with them is, primarily, make sure that your apps close their file handles before removing a file. If you want to find the app that’s responsible for them do ‘lsof’ on the file *on the client side*. If the file doesn’t have any open handles, then the client probably crashed before removing them and they can be safely deleted.


  • Thanks Pete and James for pointing to this detailed page on NFS. I was unable to find this from google and now I clearly understand why these files occur.


  • “Denniston, Todd A CIV NAVSURFWARCENDIV Crane, JXVS”

    Thanks for the warning — I´ll change it accordingly for just in case. Corrupted data is bad …