#1820 Issue `closed`: Rear recover overwrites Mountpint ownership xxx to root¶

Labels: support / question, fixed / solved / done

nirmal21s opened issue at 2018-05-28 16:24:¶

Relax-and-Recover (ReaR) Issue Template¶

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

ReaR version ("/usr/sbin/rear -V"):2.3
OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"):RHEL 7.5
ReaR configuration files ("cat /etc/rear/site.conf" or "cat /etc/rear/local.conf"):

SERVER=
NSR_CLIENT_MODE=yes
OUTPUT=ISO
ISO_PREFIX="rear-nsr-$HOSTNAME"
BACKUP=NSR
OUTPUT_URL=file:///isorear/rear
export TMPDIR=/isorear/temprear
MODULES_LOAD=( tg3 igb )
#
# Static IP (no DHCP!)
USE_DHCLIENT=
USE_STATIC_NETWORKING="y"
# NTP
TIMESYNC=NTP

System architecture (x86 compatible or POWER and/or what kind of virtual machine):x86_64
Are you using BIOS or UEFI or another way to boot? BIOS
Brief description of the issue: After rear recovery from ISO , one mount point has root ownershop. looks like it has overwritten .
The below FS ownership should be like below. But after restore it was changed to root.

/opt/xxxxx 1775 gemapp gtousers
But on checking "directories_permissions_owner_group" the permission was "/opt/xxxxx 1775 gemapp gtousers"..

Work-around, if any:

nirmal21s commented at 2018-05-29 02:22:¶

@gdha @hpannenb
For this issue , i hope this entry will solve this issue "DIRECTORY_ENTRIES_TO_RECOVER="
But i am confused with the syntax , kindly correct me if i am wrong .
DIRECTORY_ENTRIES_TO_RECOVER=( '/opt/xxxxx 1775 gemapp gtousers' )
But this mount points has no links

nirmal21s commented at 2018-05-29 02:31:¶

Attaching the $VAR_DIR/recovery/directories_permissions_owner_group , In which the permission and ownership is saved correct. But during the recovery its saving as "root"
directories_permissions_owner_group.txt

gdha commented at 2018-05-29 07:39:¶

@nirmal21s Try to add CLONE_ALL_USERS_GROUPS=yes to your local.conf file as I think your users and groups were not known within the rescue environment.

nirmal21s commented at 2018-05-29 08:03:¶

@gdha
Thanks

jsmeix commented at 2018-06-04 12:35:¶

@nirmal21s
you changed your https://github.com/rear/rear/issues/1820#issuecomment-392688374
from Thanks . it worked to plain Thanks.
Does it mean it did not work?

nirmal21s commented at 2018-06-04 17:53:¶

Now only we are doing the testing with now with CLONE_ALL_USERS_GROUPS=yes.
Soon i will update.

nirmal21s commented at 2018-06-05 04:18:¶

@jsmeix
This option also not worked. But the files under that directory has been restored with correct permission and ownership.
Still the directory recreated as root only .
thinking to try DIRECTORY_ENTRIES_TO_RECOVER =( '/opt/xxx 1775 myowner mygroup' )
kindly provide your feedback.

jsmeix commented at 2018-06-11 13:29:¶

@nirmal21s
to be able to find out when exactly permissions and ownership changes
you would need to use our current ReaR upstream GitHub master code
because after the ReaR 2.3 release I added a migration mode confirmation
directly after restore of the backup (i.e. at beginning of finalize stage), cf.
https://github.com/rear/rear/pull/1758

In general I recommend to use our current ReaR upstream GitHub master code
because that is the only place where we fix bugs - i.e. bugs in released
ReaR versions are not fixed by us (i.e. by ReaR upstream).
Bugs in released ReaR versions that got fixed in current ReaR upstream
GitHub master code might be fixed (if the fix can be backported with reasonable effort)
by the Linux distributor wherefrom you got your ReaR version.

To use our current ReaR upstream GitHub master code
do the following:

Basically "git clone" it into a separated directory and then
configure and run ReaR from within that directory like:

# git clone https://github.com/rear/rear.git

# mv rear rear.github.master

# cd rear.github.master

# vi etc/rear/local.conf

# usr/sbin/rear -D mkbackup

Note the relative paths "etc/rear/" and "usr/sbin/".

To enforce migration mode during rear recover
call in the running ReaR recovery system

# export MIGRATION_MODE='true'

directly before you call "rear recover".

In MIGRATION_MODE manual disk layout configuration happens
via several user dialogs.

In this case in particular the user confirmation dialog after backup restore
is of interest that shows up as follows:

Confirm restored config files or edit them
1) Confirm it is OK to recreate initrd and reinstall bootloader and continue 'rear recover'
2) Edit restored etc/fstab (/mnt/local/etc/fstab)
3) View restored etc/fstab (/mnt/local/etc/fstab)
4) Use Relax-and-Recover shell and return back to here
5) Abort 'rear recover'

There select Use Relax-and-Recover shell and return back to here
which gets you into a (sub)-shell where you can inspect the up to that point
recreated system below /mnt/local/ and check what permissions and ownerships
there are directly after the backup was restored.

FYI
for another example how to use that you may have a look at
http://lists.relax-and-recover.org/pipermail/rear-users/2018-April/003547.html
cf. https://github.com/rear/rear/pull/1758#issuecomment-386311817

jsmeix commented at 2018-06-11 13:40:¶

@nirmal21s
I forgot that in MIGRATION_MODE there is another user confirmation dialog
that should help to find out when exactly those unexpected permissions and
ownerships are set.

That other user confirmation dialog happens directly after the disk layout
was recreated (i.e. it happens directly before the backup gets restored).
That other user confirmation dialog shows up as

Confirm the recreated disk layout or go back one step
1) Confirm recreated disk layout and continue 'rear recover'
2) Go back one step to redo disk layout recreation
3) Use Relax-and-Recover shell and return back to here
4) Abort 'rear recover'

where you also should select Use Relax-and-Recover shell and return back to here
and inspect the up to that point recreated system.

jsmeix commented at 2018-06-11 14:14:¶

@nirmal21s
things in DIRECTORY_ENTRIES_TO_RECOVER
are not created if they already exist, see the
usr/share/rear/restore/default/900_create_missing_directories.sh
script (cf. the DIRECTORY_ENTRIES_TO_RECOVER description in default.conf)
that is run at the end of the backup restore (i.e. intentionally after the backup restore)
https://github.com/rear/rear/blob/master/usr/share/rear/restore/default/900_create_missing_directories.sh
that reads (excerpts):

  # Create only symlinks if the symbolic link name does not yet exist (regardless in what form)
  # so that things that have been already restored from the backup do not get changed here:
...
  # Create only directories if nothing with that name already exists (regardless in what form)
  # so that things that have been already restored from the backup do not get changed here:

I.e. DIRECTORY_ENTRIES_TO_RECOVER is only intended to create missing stuff
that was not already restored from the backup - it is intentionally not intended to
overwrite anything that was restored from the backup.

nirmal21s commented at 2018-06-12 14:01:¶

@jsmeix Thanks a lot .. it worked out..
Issue has been issue

jsmeix commented at 2018-06-12 14:18:¶

@nirmal21s
thanks for your feedback!

[Export of Github issue for rear/rear.]

#1820 Issue closed: Rear recover overwrites Mountpint ownership xxx to root¶