Hi! I have an old FC5 server and want to migrate to a new Centos 5.5 server. When I try to restore the backup file of a Virtual Server, I get this error:
Restore Virtual Servers
Starting restore of 1 domains from local file /tmp/.webmin/backup.tgz ..
Extracting backup archive file .. .. done
Restoring backup for virtual server icormo.com ..
Restore failed : setquota: Bad inode hardlimit: /home setquota: Usage: setquota [-u|-g] [-x] [-F quotaformat] <user|group> -a|... setquota [-u|-g] [-x] [-F quotaformat] <-p protouser|protogroup> <user|group> -a|... setquota [-u|-g] [-x] [-F quotaformat] -b -a|... setquota [-u|-g] [-x] [-F quotaformat] -t -a|... setquota [-u|-g] [-x] [-F quotaformat] <user|group> -T -a|... Bugs to: mvw@planets.elm.net, jack@suse.cz
Thank you, Humberto
i am having this problem as well -- can someone shed light on this perhaps?
Just to check out if that's the only problem: Does the restore work if you turn off "Administration user's password, quota and Cron jobs" under "Features to restore"?
Nope, same error Locutus.
Okay, it might help to turn on Webmin's debugging log to see which commands are executed exactly. You do that in Webmin -> Webmin ->Webmin Configuration.
My best guess right now is that the quota command for some reason has an incorrect format or parameter for your distro or situation. But without seeing which command VMin tried to execute exactly, it's hard to guess further. :)
Also, when you paste text output from the console, please enclose them in
Please see attached the 100 log lines after hit the 'RESTORE NOW' button, in the new server (Centos 5.5) If I restore in the same server (FC5), there are no errors and the restore complete nice.
Okay, according to your log, VMin is trying to execute this command:
setquota -u 0 0 0 0 \/homeThere is an additional space (not visible here due to website formatting) between the -u and the first 0. According to man page, the proper syntax for setquota here is
setquota -u name block-softlimit block-hardlimit inode-softlimit inode-hardlimit filesystem...It would seem that the command in your case omitted the "name" part, which should have been a username or a UID. So the first 0 was interpreted as UID, and the filesystem as "inode-hardlimit". Hence the error you receive... "/home" is not a valid value for "inode-hardlimit" which should be a number.
I can't reliably tell though why VMin would omit the username there (it definitely must not - since this obviously results in a wrong command). Do you have quotas in use at all on your system? It is conceivable that this is a follow-up error due to a failed attempt to retrieve the user name/ID for the domain being restored in some earlier command, which might have resulted in an empty string.
I suppose one of the coder team would have to shed more light on this. :)
Thank for your log analysis Locutus!
Regarding your question, the answer is yes, I have quotas in use in both systems.
I keep waiting for a workaround.
I suppose you could file this as a bug report in the Issues section, then the coders will surely read it... Provided that you didn't do "anything wrong" while creating the backup - which I don't really think you even can normally - this error should not occur and might be a VMin bug.
Maybe repeat your description there and add the additional info we found out. You might include a link to this forum thread to the report.