Hi, I have 2 servers running virtualmin pro. For backup purposes I occasionally want to backup from server1 and restore to server 2.
Almost all my virtual hosts complete successfully this backup/restore except a couple.
I run the following restore command
restore-domain.pl --source /backup/virtualmin/partial/domain.gr.tar.gz --domain domain.gr --feature dir --feature logrotate --feature unix --feature webalizer --feature webmin --feature virtualmin --feature web --feature mail --feature ftp --only-features --no-reuid
I get the following error
Restore failed : Failed to open /home/domain/fcgi-bin/php5.fcgi.webmintmp.12988 : Permission denied
Either with permissions 750 or 755 to the fcgi-bin directory and php5.fcgi file the same error occures. In the meantime other virtualhosts complete successfully the restore even with 750.
I can't figure out what the problem might be. I have enabled fcgid on all hosts recently (some months ago) and they execute fine.
Is there any configuration in the primary or the backup virtual server I should check?
I am really stuck in this and I would appreciate any suggestions.
Thanks!
Comments
Submitted by JamieCameron on Thu, 05/20/2010 - 12:50 Comment #1
Does it help if you try removing the immutable bit from that php5.fcgi file, with a command like :
chattr -i /home/domain/fcgi-bin/php5.fcgi
Also, does this specific domain use fcgi for PHP execution?
Submitted by web_support@web... on Fri, 05/21/2010 - 14:45 Pro Licensee Comment #2
I tried the chattr command but it seems that the filesystem I am using (reiserfs) either does not support it or has issues with chattr.
Then I checked whether fcgi is enabled on the domain. It is enabled in the master server but it was not in the backup server. You were right. I tried enabling it on the backup server. It can apply Apache mod_php successfully but when i select FCGId (run as virtual server owner) it gives me the same error as in the restore operation. On the master server any changes apply successfully, so something is different on the backup server. Also fcgid is globally enabled and working on other domains in the backup server.
However Permissions are the same on master and slave server.
If you cannot think of anything simple that might be causing this, it might have to do with my setup.
Here is what is unusual in my 2 servers setup that might have to do with it.
In my first backups of all domains I didn't select no reuid on restore. I changed that after some time for all domains by editing /etc/passwd /etc/group, changing permissions in home dirs , and the suexec directive of the apache conf file. These complicated changes worked for all domains, but I might have missed some change in this domain. I think I have found the id and changed it also in a config file of webmin or virtualmin. I can't remember which file it was.
Is there a config file in webmin or virtualmin where the user or group id is stored?
Do you have any suggestions?
Submitted by JamieCameron on Sat, 05/22/2010 - 01:49 Comment #3
What output do you get it if you run the command
lsattr /home/domain/fcgi-bin/php5.fcgi
on both the source and destination systems?Also, does simply deleting that file on the destination help?
Finally, are both the source and destination systems using reiserfs?
Submitted by web_support@web... on Sat, 05/22/2010 - 02:22 Pro Licensee Comment #4
I get this result on both domains
Both servers are using reiserfs
I deleted the file on the destination server and then i tried again from the website options. I got the same error.
Then I changed file permissions to 777 for that folder and i tried again. There it is. It is indeed my leftovers from my first restore when i hadn't used no-reuid 2 years ago. File is created with user id 1015 and group id 1022. However now user id should be 1013 and groupid 1015. It is changed in /etc/passwd and /etc/group.
It is not easy to simply delete the domain in the slave server and start a clean restore since i have mysql replication running and that would cause the databases to be deleted from the master server as well.
Where does virtualmin get these uid and gid values? They are not in /etc/passwd and /etc/group anymore. If I can change that values there I think it would work.
Thanks again.
Submitted by JamieCameron on Sun, 05/23/2010 - 14:24 Comment #5
Virtualmin has it's own record of the UID and GID for each domain, which is in the domain's data file in /etc/webmin/virtual-server/domains . You can get the ID for a domain with a command like :
virtualmin list-domains --domain whatever.com --id-only
Submitted by web_support@web... on Tue, 05/25/2010 - 09:09 Pro Licensee Comment #6
Problem solved!
The uid, gid and ugid values in the domain I was trying to restore on the backup server had different values because I hadn't used --no-reuid on the initial backup a year ago. After manually changing values in /etc/passwd and /etc/group and in user files to match with the master server, it seems I missed changing these values there also.
It was not the only domain I made that mistake, so I wrote downa bash script to check and fix all domains.
I experienced other kinds of problems as well, like creating an ftp user in one domain that appeared under another and I couldn't figure out why.
Probably nobody else would manually change uid and gid of a domain.
However if you think that someone else might do that also, you could add a sanity check of this kind in a future version of virtualmin.
I am attaching the bash script I wrote, to detect and fix this values if you would like to see it.
Thanks!
Submitted by xenofx on Tue, 05/09/2017 - 05:22 Comment #7
can you attach bash script to here ?
Submitted by web_support@web... on Tue, 05/09/2017 - 06:20 Pro Licensee Comment #9
This is a very old bug and i haven't used this script for about 6 years as this problem did not reappear on me. Maybe it is safe now, maybe it is not, so take backups if apply changes
See bottom of script for usage
Submitted by xenofx on Tue, 05/09/2017 - 12:41 Comment #10
I try your script from root folder with "bash duzelt.sh do_checkuids -f" command. but nothing changed. is it correct ?
cat: unrecognized option '--name-only'
Try 'cat --help' for more information.
cat: unrecognized option '--name-only'
Try 'cat --help' for more information.
id: unrecognized option '--name-only'
Try 'id --help' for more information.
id: unrecognized option '--name-only'
Try 'id --help' for more information.
Domain do_checkuids : OK
cat: invalid option -- 'f'
Try 'cat --help' for more information.
cat: invalid option -- 'f'
Try 'cat --help' for more information.
id: invalid option -- 'f'
Try 'id --help' for more information.
id: invalid option -- 'f'
Try 'id --help' for more information.
Domain -f : OK
Submitted by web_support@web... on Wed, 05/10/2017 - 07:36 Pro Licensee Comment #11
This is a 7 year old bug report. I suggest you file a new bug report describing your problem and get official support. I am just a user like you and I can't help you further.
Submitted by andreychek on Wed, 05/10/2017 - 08:27 Comment #12
Thanks for providing your script and lending a hand! You're right, this is indeed an old request -- we'll go ahead and mark this as closed.
xenofx, if you're seeing a bug, feel free to open a new bug report. There, describe what issue you're seeing, and what Virtualmin version you have there. Thanks!
Submitted by andreychek on Wed, 05/10/2017 - 08:28 Comment #13