Backup restore failed on NFS mount

Hestia Control Panel
#1

Hi, I’ve mounted /backup on a NFS (synology) storage

backup work ok as normally, I downloaded it and checked, and is OK

the problem is the restore (of the web) that return an error

from HESTIA/log/resore.log :

– WEB –
2020-08-13 14:33:16 DOMAIN
tar (child): /backup/tmp.XeWD5mia9m/web/DOMAIN/domain_data.tar.gz: Cannot open: Permission denied
tar (child): Error is not recoverable: exiting now

gzip: stdin: unexpected end of file
tar: Child returned status 2
tar: Error is not recoverable: exiting now
Error: Can’t unpack DOMAIN data tarball

and from HESTIA/log/error.log :

2020-08-13 14:33:38 v-restore-user ‘admin’ ‘admin.2020-08-13_14-30-02.tar’ 'DOMAIN ’ ‘no’ ‘no’ ‘no’ ‘no’ ‘no’ ‘yes’ [Error 12]

Since the backup is successful created I’m assuming that permission are ok, but restore failed…

any ideas?

#2

Can you post the file permissions in /home/$user/web/$domain/ ?

ls -la /home/USER/web/DOMAIN

#3

sure:

total 36
drwxr-x--x 9 admin admin    4096 Aug 13 14:14 .
drwxr-x--x 3 admin admin    4096 Aug  3 23:20 ..
drwxr-x--x 2 admin admin    4096 Aug  3 23:20 cgi-bin
drwxr-x--x 2 admin admin    4096 Aug 13 14:14 document_errors
dr-xr-x--x 2 admin admin    4096 Aug 13 14:14 logs
drwxr-x--x 2 admin admin    4096 Aug  3 23:20 private
drwxr-x--x 2 admin www-data 4096 Aug 12 14:26 public_html
drwxr-x--x 2 admin www-data 4096 Aug  3 23:20 public_shtml
drwxr-x--x 2 admin admin    4096 Aug  3 23:20 stats

I tried to umount the nfs directory, and with normal /backup folder the restore works…

#4

first thanks for the detailed information!

I think the nfs mount might not be able to handle unix permissions properly. so what most likely happens here is:

  1. the restore process first untars the full backup archive into that tempdir on the very same nfs mount, which includes different ‘sub’ archives for each domain and mail and db and so on…
  2. during the next step these individual archives are picked up and to be extracted with only user-specific exec rights (not admin/sudo) and because the untar in step 1. probably could not set the owner due to it being an nfs mount you end up with that ‘permission denied’ error that you can see in your logfile

maybe you can check the owner of your files within the nfs mounted backup-dir, I’d guess this some specific owner relating to what you need to use for the nfs mount to work at all.
is that by any chance a hetzner storagebox or something like that?

that creating backups is working simply is because it’s the other way round with no user_exec involved if I am not mistaken. so it’s just bringing everything directly into the archive file, no importance who owns that file afterwards

I will check if I can somehow recreate an environment with an nfs mount to see for myself, but no promise on a timeframe.
also, if it really is about the owner/permissions you can probably try to edit the hestia v-restore file and remove the ‘user_exec’ from that specific part where it extracts that domain data tarball, but no guarantues, haven’t played with that in a while.

you could also mount your nfs somewhere else, create a bigger image-file on it which you can format as ext4 or whatever and then mount this image to your backup folder. that way it doesn’t matter if the image file can only owned by the nfs-user - however it’s a bit more complicated to set up with the double mount :wink:

1 Like
#5

first of all thanks for detailed explanation !

this help me to find more than a solution!

  1. removing user_exec I confirm that the restore process works, and the permissions are ok (it seems)
  2. changing the extract folder to /tmp on line 219 (v-restore-user) works

BACKUP_TEMP="/tmp"

  1. which one I used (I don’t like to edit source code), I found a setting on NFS storage “Map all users to admin” (admin is a storage administrator) so I think independent of which user is used in hestia it works!

The storage I use is a local storage (synology) on the LAN

thanks!

2 Likes
#6

glad you found not only one but three solutions :+1: :grin:

but even more thanks for your detailed response and solutionsharing, as I am sure that this will be of help for others in the future as well!

btw. I totally agree, not having to change the source code is the best practise here, as these changes will be overwritten, if there any updates to that file with a future release, so the problem would always come back…

2 Likes