Scheduled Backup fails unless I create .backup dir manually

SYSTEM INFORMATION
OS type and version Ubuntu 26.04
Webmin version 2.651
Virtualmin version webmin-virtual-server 8.1.0-1-gpl
Webserver version nginx/1.28.3
Related packages SUGGESTED

Hi all.

I’m getting this weird bug on one of my virtual servers. Other servers don’t get the same bug.

When I manually create an empty .backup directory inside the home folder of the user, it runs fine. I am getting the same error not only with the mariadb backup, but with other things like the dns records.

Case 1:

Case 2:

Backup failed! See the progress output above for the reason why. Total backup time was 00 minutes, 04 seconds.

Virtual servers that failed :
    XXX
Sent by Virtualmin at: XXX

Testing backup destination 08-07-2026 in S3 bucket XXX using XXX ..
.. done

Creating backup for virtual server XXX ..
    Copying virtual server configuration ..
    .. done

    Backing up Cron jobs ..
    .. none defined

    Copying records in DNS domain ..
    .. backup of dns failed : Failed to open /home/XXX/.backup/XXX_dns_dnssec_keyinfo for writing : No such file or directory

Home folder permissions (for the vhost in question): 0750

Other hosts in the system, with the exact same perms, don’t have the same error. The system is very freshly installed (barely a week old), on a fresh OS installation.

Any help will be greatly appreciated! :slight_smile:
Thanks,
Kyriakos

When my schedule backups run its uses /tmp/.webmin and I don’t see /home/domain/.backup being created.
Did you change default location?

In webmin is your temp location set like this

You’re right, it wasn’t set like that. Once I used the default it worked ok.

What could’ve set it this way though? I didn’t touch it and it’s a fresh server…

Thats not in the Supported A grade OS for virtualmin, maybe thats the cause, not sure why though..

Ok, it was unrelated to the /tmp/.webmin dir change.

It was actually a race condition. As I have 2 scheduled backups running on the same domains, at the same time, they collide with each other: one of them deletes the .backup dir when it’s done while the other one is working on it at the same time, boom, failed.

This is why I said that changing the tempdir fixed the problem: it didn’t. It was just a coincidence, as I was running the backup manually, not on schedule, so it didn’t have other backup op to collide against.