Regenerate or rebuild the "rights file" or "rights database" for setting correct file permissions on next restore?

Support
1

When restoring files, Nethserver sets their rights (apparently) using an existing rights file or rights database. However, their entries do not appear to correspond to the current system status. Is there a way to somehow regenerate or rebuild this rights file or rights database?

Background:
A few days ago I wanted to restore some folders from a backup. Unfortunately, I called the wrong function, namely “Restore” under “System >> Backup” instead of “Restore Data” under “Applications”. (Yes, I know, there is a little hint, but I was stressed and overtired - an ugly combination)

By the time I realized the error, it was too late, the full recovery had begun. Unfortunately, I didn’t have time to wait for the full restore and a full system reset would have been even more problematic than somehow aborting the restore. So I stopped the VM first, stopped after a moment’s thought, and then did a mixed restore from a recently backed up system partition and the current partition with the “nethserver” path.

This mixture led to various authorization problems in the system and user files. With some effort and in constant comparison with a VM of an older version, I corrected the permissions and restored the functions (so it seems).

As a lesson from the disaster, I not only ordered new glasses and a work timer, but also looked at other backup options. In addition to duplicity, I always had an external rsync backup running, but the Nethserver’s own functions certainly have advantages in the event of a restore (unless you press the wrong button).

So I set up an rsync backup via sftp which also works very well and shows up as successful - after removing a few entries from the include lists from previously installed applications (FreePBX and HylaFax).

To test whether this backup can also be restored, I first restored some files (as a copy). I then noticed that the permissions for the restored files are completely different than in the current system (and in the backup). However, the user and group IDs seemed strangely familiar to me from the time I had to fix the permissions after the restore was aborted. Apparently the authorization was generated from a rights file or rights database that does not correspond to the current situation.

Is there a way to somehow regenerate or rebuild this rights file or rights database?

Thank you for your help!

1 Like
2

NethServer backups the ACLs in /var/lib/nethserver/backup/acls.dump

You may try to reset permissions for shared folders, see authorizations:

grafik
grafik984×276 26.8 KB

1 Like
3

Mhh, i know this procedere to correct wrong permissions in shared folders.
But will this work to reset or renew the ACLs in /var/lib/nethserver/backup/acls.dump?

Or would this (wrong) ACL List used then to “correct” permissions in shared folder?
In this case, the ACLs in shared folders would go completely wrong, so i dont try this without informations.

4

It will reset the shared folder to the ACLs you set in the shared folder settings (and will delete all your custom set ACLs for subdirs or files):

grafik

In the web UI you can only set ACLs for the share (top-level).
/var/lib/nethserver/backup/acls.dump is just created before a backup starts to be able to backup (and restore) all the ACLs (You could have set them from a client).
You could check if acls.dump contains the wrong permissions.

5

/var/lib/nethserver/backup/acls.dump is just created before a backup starts to be able to backup (and restore) all the ACLs

Thank you! This is the needed answer!

You could check if acls.dump contains the wrong permissions.

As i can see, the ACLs in this file are correct, because this ACL list is namebased. So my thinking was going to the wrong direction and there is an other problem.

But if i restore a file, the restored file shows (e.g with “ls -al”) wrong user (and group?) ownerships, the permission is shown not as name but as number. So i think, there is no user or group to this IDs. I dont have tested the ownerships with getfacl yet.

The tm_rsync itself saves the files on my storage (debian) with uniq ownerships (if i remember, there are always the same ownerships on all files and folders). Maybe i should compare this ownerships (IDs) with the IDs on restored files. I will also look again on all steps of restoring and this log for errors. Maybe the restoring process has an error.

6

In the meantime I have tested a file recovery from an rsync backup again and observed the following:
(I hope this topic doesn’t deviate too much from my original question)

Test 1
A file is restored from a user account via “Applications/Restore data”, i.e. from a path based on the pattern “var/lib/nethserver/home/username/testfile.xyz”.

Variant A: Restored as a “copy” (not overwritten), the file is owned by “root:root” (0:0) after the restoration. The restored file has not the ownership saved in ACLs.dump,
In addition, the access rights are set differently than in the original, the original file has “-rw-r–r–” , the restored file has “-rw-rw----”.

Variant B: The file is (or remains) restored by overwriting after the restoration in the possession of the user or group used for the SFTP transfer (user account on the backup host). The restored file also has not the ownership saved in ACLs.dump, however, the access rights are set correctly with “-rw-rw----”.

In both cases, after restoring, the file does not retain the ownership saved by ACLs.dump.

(Edit: I can not found any logged errors from “/usr/bin/sudo /usr/libexec/nethserver/api/nethserver-restore-data/execute”)

As a further test, I wanted to restore a file from a share, i.e. from a path like “/var/lib/nethserver/ibay/Share_XYZ/”.
Unfortunately, this failed because I didn’t see any files from paths below “ibay” in the “Applications/Restore data” search.

I’m trying it now on another machine that didn’t have permissions issues before.

As i remeber, restoring from Duplicity backups was correct in the past. Which would the correct behaviour when restoring files from a rsync backup?

7

ok, on another machine (without previous history) the problem is the same. i think it’s a bug, i’m preparing a bug report.