Restoration of virtual servers fails - gunzip failure v2

OS type and version CentOS Linux 7.9.2009
Webmin version. 1.991.
Virtualmin version 7.0


I have restored many backups without problem and now suddenly I get an error when restoring the database, the same thing happens to me as in this post. 5 years later

error details

Error Details

 Restoring allowed MySQL hosts ..
.. done
Re-loading MySQL database ganapathi ..
.. gunzip failed!
gzip: /tmp/.webmin/881284_20040_2_restore.cgi/mydomain.org_mysql_ganapathi: Permission denied
Applying web server configuration …
… done
… failed! See the progress output above for the reason why.

I change the permission of this folder to 777 and nothing.

thank you very much

I’ve been all over search and these forums today with the same issue! The restore works fine except for importing the database content:

    Re-loading MariaDB database [DB_NAME] ..
        Creating MariaDB database [DB_NAME] ..
        .. done

    .. gunzip failed! gzip: /tmp/.webmin/[DOMAIN]_mysql_[DB_NAME]: Permission denied

I have to manually import the sql dumps so it’s not ideal.

Both servers are Debian 10 & MariaDB version 10.3.34

Backup is from:
Webmin version 1.981
Usermin version 1.823
Virtualmin version 6.17-3

Restore is to:
Webmin version 1.991
Usermin version 1.840
Virtualmin version 7.0-4

I am thinking maybe the backup Virtualmin version needs to be updated because this worked on a couple of accounts before I updated the new server today.

Just to add my 2c, I’m having the same issue.
Backup made on 6.17 , restoring on 7.0

gzip: /tmp/.webmin/154939_6940_1_restore.cgi/mysql: Permission denied

A resolution will be GREATLY appreciated. Thank you.

1 Like

@Jamie, as we changed backing up format, we should handle restore to support both formats (where internally database file name has extension and where is not).


Yes, that was the idea … however, I found a bug in the code that uncompresses the .gz files. The fix can be seen here : Fix restore of compressed MySQL databases… · virtualmin/virtualmin-gpl@5293e5a · GitHub


Great news!
Do updates like this linger in Git or is it likely that an update will be be pushed out ‘Real Soon Now’ :grinning:

FYI : same issue on Debian 10 systems, but Jamie’s fix did the trick.

Fabulous, that worked, thank you. edited
with changes on git


1 Like

@Jamie I know enough to make me dangerous enough to break the whole system. So with due respect what is the easiest step- by-step process to resolve this as my restores are failing with the exact same message.

you’ll want to edit the file in /usr/share/webmin/virtual-server/features/
with the changes on the github link @Jamie created for the fix.
here it is again: thank you for your quick response. I did gather from your previous comment where thiss file could be located and tracked it down. I did make a backup of the original just in case i messed up. I also had to revert my file permissions as I did change them when I saw the initial permissions denied messaged. I will say crisis averted thanks to hints in your comment. I guess my initial question would not have cropped up if there was an explanation of which file needed to be modified

do you have fix in nimd?

Thanks for the fix @Jamie ! FYI : It works great as sudo on command line restore, but it still fails (same error) as a regular user on the Virtualmin web interface. Or maybe I needed to re-start Webmin in case the perl file was cached maybe.

Same here, still fails restore from web interface (root login) does re-start Webmin help? or do I need to go command line ?
source CentOS Linux 6.10 / Virtualmin version 6.16 Pro
target Ubuntu Linux 20.04.4 Virtualmin version 7.0-4

So if a server admin, who believes that keeping on top of updates, because that is what you do to protect your servers, unknowingly does updates, they will have unwittingly broke their server. Not just the backups. I have recently updated two servers and one of them still does not work (can’t start mySQL). I now have several servers I am afraid to update. What if you are not comfortable doing command line fixes and editing .pl files? I used to have all pro machines - but when I could not get help fixing stuff I gave up most of the pro licenses. Guess I am getting too old for this crap and need to retire. And no mention of when things will just work. Yes I am whining, but it makes me damn unhappy when perfectly good servers get damaged by updates.

ERROR: Re-loading MySQL database echohosting …
… gunzip failed!
gzip: /tmp/.webmin/862828_105916_1_restore.cgi/echohosting.net_mysql_echohosting: Permission denied-

I don’t have a folder called features. Ubuntu 20.4 I could use some very specific instructions - like talking to a 10 year old. Not great with code or hacking scripts. I will if I have to. Can anybody kindly tell me what exactly I should do. I have 42 accounts I need to restore to a new machine. Please help Mr. Wizard.

Guys would you care to elaborate how to restore from an older system to the latest ? I have replaced the with the new one mention here but same results. Are you still working on a solution or are we doing it wrong ? Will command line restore help?
This is obviously urgent matter.

I am anxiously awaiting this as well. With recent updates rendering backups unusable, a patch to fix this is an urgent priority. Thank you.

gzip: /tmp/.webmin/439595_2126_2_restore.cgi/(my)site.com_mysql_oys: Permission denied

This is a known issue that makes backups unuseable and a fix hasn’t been released more than two weeks later? That could be devastating for some people, at least in my case it’s for a minor site, but man, this could be awful for larger sites and companies that are depending on Virtualmin backups being as reliable as they have been in the past.

Seems odd that Virtualmin hasn’t pushed a fix out yet, especially if one is available. Wonder what’s going on…?

The fix does work. On my centos I found the file in usr/libexec/webmin/virtual-server/

If you are having trouble finding the file to edit, use the virtualmin file manager, go to the top level, then click on ‘tools’, and search for

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.