Hello!
I imported a backup saved from Vesta to Hestia.
The problem is this. Unfortunately, not all backups could be restored, you did not want to restore the databases yourself.
Eventually, I restored them one by one. But there are strangers, both on the web and in the field of databases.
Websites have permission issues accessing some files and some editing databases. What could be the reason I could improve?
Thx.
Hi @raptor666
Without any additional informations like output of v-restore-user, logs, os and hestia version it is srsly hard to tell you what could be wrong 
.
Infact it could also be a restore issue, the right place would be our github issue tracker, so we can track it down: https://github.com/hestiacp/hestiacp/issues/new
OS: Debian 10 64 bit
Hestia: 1.2.2
2020-07-11 01:43:33 v-restore-user ‘adrianweb-1’ ‘adrianweb-1.2020-07-10_18-05-31.tar’ [Error 3]
2020-07-11 01:43:33 v-restore-user ‘adrianweb-1’ ‘adrianweb-1.2020-07-10_18-05-31.tar’ [Error 3]
2020-07-11 01:43:43 v-restore-user ‘adrianweb-1’ ‘adrianweb-1.2020-07-10_18-05-31.tar’ [Error 12]
2020-07-11 01:44:51 v-restore-user ‘aquapet-1’ ‘aquapet-1.2020-07-10_18-06-30.tar’ [Error 3]
2020-07-11 01:44:51 v-restore-user ‘aquapet-1’ ‘aquapet-1.2020-07-10_18-06-30.tar’ [Error 3]
2020-07-11 01:44:57 v-restore-user ‘aquapet-1’ ‘aquapet-1.2020-07-10_18-06-30.tar’ [Error 3]
2020-07-11 01:45:13 v-restore-user ‘aquapet-1’ ‘aquapet-1.2020-07-10_18-06-30.tar’ [Error 12]
2020-07-11 01:46:30 v-restore-user ‘balintjanos11-1’ ‘balintjanos11-1.2020-07-10_18-07-29.tar’ [Error 3]
2020-07-11 01:46:31 v-restore-user ‘balintjanos11-1’ ‘balintjanos11-1.2020-07-10_18-07-29.tar’ [Error 3]
2020-07-11 01:46:35 v-restore-user ‘balintjanos11-1’ ‘balintjanos11-1.2020-07-10_18-07-29.tar’ [Error 3]
2020-07-11 01:46:41 v-restore-user ‘balintjanos11-1’ ‘balintjanos11-1.2020-07-10_18-07-29.tar’ [Error 12]
2020-07-11 01:47:25 v-restore-user ‘enicotreasures-1’ ‘enicotreasures-1.2020-07-10_18-07-32.tar’ [Error 3]
2020-07-11 01:47:25 v-restore-user ‘enicotreasures-1’ ‘enicotreasures-1.2020-07-10_18-07-32.tar’ [Error 3]
2020-07-11 01:47:28 v-restore-user ‘enicotreasures-1’ ‘enicotreasures-1.2020-07-10_18-07-32.tar’ [Error 12]
2020-07-11 01:48:46 v-list-dns-records ‘balintjanos11-1’ ‘wellnessandwine.hu’ [Error 3]
2020-07-11 01:49:49 v-restore-user ‘szantai-1’ ‘szantai-1.2020-07-10_18-33-05.tar’ [Error 3]
2020-07-11 01:49:50 v-restore-user ‘szantai-1’ ‘szantai-1.2020-07-10_18-33-05.tar’ [Error 3]
2020-07-11 01:49:52 v-restore-user ‘szantai-1’ ‘szantai-1.2020-07-10_18-33-05.tar’ [Error 12]
2020-07-11 01:51:19 v-restore-user ‘szilda-1’ ‘szilda-1.2020-07-10_18-33-38.tar’ [Error 3]
2020-07-11 01:51:20 v-restore-user ‘szilda-1’ ‘szilda-1.2020-07-10_18-33-38.tar’ [Error 3]
2020-07-11 01:51:24 v-restore-user ‘szilda-1’ ‘szilda-1.2020-07-10_18-33-38.tar’ [Error 3]
2020-07-11 01:51:27 v-restore-user ‘szilda-1’ ‘szilda-1.2020-07-10_18-33-38.tar’ [Error 12]
2020-07-11 01:52:13 v-restore-user ‘vbalazs-1’ ‘vbalazs-1.2020-07-10_18-40-53.tar’ [Error 3]
2020-07-11 01:52:14 v-restore-user ‘vbalazs-1’ ‘vbalazs-1.2020-07-10_18-40-53.tar’ [Error 3]
2020-07-11 01:52:14 v-restore-user ‘vbalazs-1’ ‘vbalazs-1.2020-07-10_18-40-53.tar’ [Error 3]
2020-07-11 01:52:16 v-restore-user ‘vbalazs-1’ ‘vbalazs-1.2020-07-10_18-40-53.tar’ [Error 12]
2020-07-11 01:52:37 v-restore-user ‘stalker-1’ ‘stalker-1.2020-07-10_18-33-04.tar’ [Error 3]
2020-07-11 01:52:37 v-restore-user ‘stalker-1’ ‘stalker-1.2020-07-10_18-33-04.tar’ [Error 3]
2020-07-11 01:52:41 v-restore-user ‘stalker-1’ ‘stalker-1.2020-07-10_18-33-04.tar’ [Error 12]
How do you try to restore the user? Please provide as much informations as possible, step by step what you’re doing and what your output is.
I logged in via SSH. Then I went to the folder of the copied backups and read their names with the ls command. and v-restore-user as follows: v-restore-user admin admin.date.tar
For this, the web began to import. But mysql doesn’t.
What I don’t understand is that vesta treated the folders in such a way that both the user and the group were their own users. Here, the user is the own and www-data of the group, in order to work properly, but do not set this, the public folder will get 1 such user: my group: www-data, but if you manually chown the files -R i don’t set the group to www-data, it doesn’t work with chmod 751. and for the files I upload on ftp, both the user and the group will be their own.
you shouldn’t manually mess around with the permissions.
user and group for the files and folder beneath docroot indeed should be the same (as you see when uploading via ftp), only the public_html has group set to www-data for proper access and that’s correct.
if you mangled with the permission on vesta already these wrong permission might carry over.
however the mysql issue is most likely not related to that, but without any kind of error message, it’s hard to say what might not be working. we had the case where the db-password couldn’t be restored, so eventually check if the databases are there and just set the password new?
No. What is included in public_html must also have the group www-data, otherwise it will not work with chmod 751 (set this by default when you upload the web from backup).
No. I could not restore the sql database of any of the websites from the vesta backup, I had to add them one by one manually.
Please describe what group public_html should be! Respectively, whether the www-data group is appropriate for the content in it, because if the user is unfortunately the group with chmod 751, it will not work properly. How can I set what I upload to ftp to get a www-data group instead of my own user? Do not fully understand.
just add a user and check the permissions that hestia sets for the default files.
don’t change the permissions manually. files and folders inside the public_html folder should belong to the user and same group.
751 is not going to work on files, because that equals rwxr-x–x
and executable rights are a bad idea for one and the files won’t be readable for the web-server
because of missing read permission for others.
files inside of public_html should have 644 and directories 755. done.
vesta may have worked with kinda borked permission because of ruid and the likes in apache. Hestia does not do that anymore and runs only the php-fpm with uid, as php is the thing that eventually writes, the webserver needs only to be able to read files.
sorry to say, but please try to understand permissions in linux and don’t mess around manually changing things to something that’s wrong anyway 
This is how you set it up during system recovery.
But WordPress detects an error. It does not allow you to upload files to the directory. (Image, other) However, if I manually switch the group to www-data, it already works.
this is a fresh os installation and hestia is also newly installed.
This error occurs in all customers.
sorry man, I give up. the permissions in your screenshots after restore look about right, changing the group manually might give kind of a temporary solution, but simply is the wrong way to go.
rather find and fix the actual error. maybe look at the log files and see what wordpress really is complaining about, probably a wrong path to a tmp or upload folder…
AH01071: Got error ‘PHP message: PHP Notice: Unknown: file created in the system’s temporary directory in Unknown on line 0PHP message: PHP Warning: File upload error - unable to create a temporary file in Unknown on line 0’
because i add a new user to it also root: root will be tmp user and his group.
the tmp folder in home / user /. I chowned to the customer’s username. this works, but for a new user, set hestiacp to the tmp folder as root. Why?
Because Hestia needs those settings. Vesta != Hestia and there have been changes due to sftp jail and other things. The aim of the system if to build a fail safe system.
Delete the account and try to reimport them. Do not change the settings and go to /var/log/(web server)/domains/{domain}.error.log and check first what kind of errors you have…
Then start from there. It is a bad decession to just chmod everything…
while the conf and mail folder are correctly owned by root, the tmp folder should be owned by the user as well and not root. that’s of course the reason why wordpress (php in general) could not upload anything then.
so the question here is, why got it changed to root in your case?
just to be sure I checked the restore script and here is the part where it creates that tmpdir:
as you can clearly see it sets the permissions and owner properly… maybe you accidentically changed that while trying around?
if it’s the same issue for other restores as well, you should check if you did something else to the permissions or owners, maybe ran some scripts after the restore that are supposed to do whatever and mess with the permissions?
No. Unfortunately, we have the tmp root: root left after import. But there is one that isn’t, it’s weird. But then I already understand the problem and operating fog. Thanks for the help.