#158 Issue closed: Detect and escalate NFS 'root_squash' (or other permission related problems) to the user

Labels: enhancement

dagwieers opened issue at 2012-09-07 09:06:

When the user has no rights to write to the destination folder (as root), we should detect and report this to the user. Causes could be NFS root_squash, read_only mounts and/or selinux.

If possible, we should analyse the permission problems and provide guidance for each specific case. Or if impossible, at least report the various causes for this issue.

This closes #146.

gdha commented at 2012-12-13 07:11:

Another point of interest is NFSv4 is not properly supported within rear at this moment. E.g. read the background details at http://blather.michaelwlucas.com/archives/796
The best we can offer at this moment is to define variable BACKUP_OPTIONS="nfsvers=2,nolock" in the /etc/rear/local.conffile. Or, use nfsvers=3 which is also not mapping the UIDs of the files/directories to -2 (on 64 bit Linux) or 4294967294 (on 32 bit Linux).

Crossed this while doing a recovery exercise using RBME and restoring over NFSv4 (on fedora 18 beta):

xenlo commented at 2013-05-29 10:14:

I want to upvote to handle the NFSv4! Because it becomes more and more the standard version for NFS.

In our case we put in place ReaR as system backup tool for our RHEL5 servers. For that we already had to adapt the NFS server to allow the RHEL5 mount the share in version 3. But now we get also RHEL6 that we need to backup. And since RHEL6 the default version used by the client is also v4!
So as workaround we had to turn off the support of v4 on the NFS server. But this is actually not a nice trick.


dagwieers commented at 2013-05-29 10:24:

@xenlo You mean adding an rpc.idmapd service to the rescue image ? It is already possible to add it yourself to the configuration file and have it started on boot. Integrating this into Relax-and-Recover should be quite easy.

bjverzal commented at 2014-10-20 18:21:

Yes - please get nfsv4 working. We cannot standardize on any other versions of NFS for security reasons. Currently, a good number of ReaR images are failing because of this. If not support, please post a workaround until supported.

gdha commented at 2014-10-21 07:53:

a work-around is BACKUP_OPTIONS="nfsvers=3,nolock"

gdha commented at 2015-01-07 12:11:

NFSv4 support post-pone to rear-1.18 release

gdha commented at 2016-02-02 16:47:

Fully NFSv4 integration into rear is postponed to 1.19. No time left for 1.18 release.

gdha commented at 2016-02-03 07:48:

We may close this issue as we have a special issue #754 for this topic.

[Export of Github issue for rear/rear.]