Virtualmin SSH backups started failing.


We have a daily backup via SSH to a remote server, which used to work just fine. Suddenly, the backup directory’s are being created but absolutely nothing is being put inside of them.

What log files should I be checking for errors? I have access to both the virtualmin server and the backup ssh server.


On a manual test, several of the virtual servers gave this:

sh: /tmp/.webmin/17112008/ No such file or directory

gzip: stdout: Broken pipe
tar: -: Cannot write: Broken pipe
tar: Error is not recoverable: exiting now

or this:

sh: /tmp/.webmin/17112008/ No such file or directory

gzip: stdout: Broken pipe
tar: -: Wrote only 4096 of 10240 bytes
tar: Error is not recoverable: exiting now

In fact, all the tars fail after the first few servers complete successfully, and finally the error below:

Uploading archive to SSH server …
… upload failed! myuser@x.x.x.x’s password: /tmp/.webmin/17112008: No such file or directory

Backup failed! See the progress output above for the reason why.

I assume that whatever is causing the original failure, is causing the fails afterward, and eventually, there is no file to upload because of those errors.

But what is causing it originally I guess is what I am wondering.<br><br>Post edited by: AbitatSupport, at: 2008/11/17 09:36


Is there enough space in /tmp for the backup? I suspect the error would be different is space were an issue, but I figure I’d ask :slight_smile:

Barring that, I might file a support request, I’m not sure what would cause the errors you’re getting.

Well, df says we have 99G left and our sites are certainly not that large.

Hum, okay thanks for the input tho :slight_smile:

Agreed, it definitely doesn’t look like a space issue :slight_smile:

Yeah, I’d file a request here, Jamie may know the case of that:

Hey there,

I’m encountering the same issues as above. Has there been any updates to the situation? My /tmp has plenty of space, as does my destination. It’s been dying periodically for like the past 3-4 weeks daily… Never on the same backups. Sometimes when I run them manually, they’ll work, but the scheduled/automatic backgrounds seem to fail.

Hrm, this particular post was last year, so I don’t really recall what came of it :slight_smile:

What specific error(s) are you seeing during the backup?


I’m seeing the exact same error as above.

Basically, after the entire ‘site’ has been tarballed, it’ll try to upload it to remote ftp and it’ll pop that error out. So, it’s almost as if the tar wasn’t created properly and doesn’t exist, or something. I haven’t been able to localize the error yet.

What is the output of these two commands:

  1. mount

  2. df -h



haha, /tmp has plenty of space, that’s the first thing I checked.

.tar.gz can be >4GB now right? It’s 2009, I wouldn’t imagine that being a limitation still??

It’s peculiar, like, not all of the ‘site’ tarball creations fail… I’ll see a bunch of successful backups created and transferred onto the remote site, just randomly one will fail.

Yes, the tar archives can be quite large these days (I don’t know about the exact limitations, but someone else was working with a 22GB file just earlier today).

However, it’d still be helpful if you offered the output of those two commands :slight_smile:


sure. It’s on a VPS so there’s no mount breakdown, just one large filesystem.

[root@la tmp]# df -h Filesystem Size Used Avail Use% Mounted on /dev/simfs 60G 12G 49G 19% / [root@la tmp]# mount /dev/simfs on / type reiserfs (rw,usrquota,grpquota) /proc on /proc type proc (rw) /sys on /sys type sysfs (rw) none on /dev/pts type devpts (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

Total backup size talking like 7.2GB or so (for about 6-7 different ‘sites’)

This is the error:

Creating TAR file of home directory …
… TAR failed! sh: /tmp/.webmin/24-08-2009/site.tar.gz: No such file or directory

gzip: stdout: Broken pipe
/bin/tar: -: Cannot write: Broken pipe
/bin/tar: Error is not recoverable: exiting now

Thanks for all the info – I had sent a message to Jamie to see if he has some thoughts on what’s going awry.


Hi guys,

I’d be interested to know exactly what settings you have for these backups that are failing, such as the backup path, format and strftime setting.

Also, do you perhaps have two backups running at the same time to remote destinations?

I do have two backups that run on the same day… The site backup runs at midnight every night, and takes about 2 hours to run a full backup.

I have another ‘virtualmin’ backup that just backs up settings that runs nightly at 2am.

Remote Backup path: /backup/sites/%d-%m-%Y
Do strftime-style time substitutions on file or directory name - Yes
Transfer each virtual server after it is backed up - Yes

Create destination directory? Yes

Halt the backup immediately [X]
Backup level [X]

The backups do have a chance to overrun each other due to the 2 hour interval I’ve put in. Each time backup runs, does it rm -rf the /tmp directory? I can see that coincedentally running if my site backup is taking longer than usual.

The two concurrent backups could cause this problem…

Do they both use the same remote backup path?


Are there any news/solutions for this issue?

Suddenly, I’m encountering the same problem. Some servers fail to backup with a message like:

Uploading archive to SSH server my.backupserver.tld …
… upload failed! /tmp/.webmin/24107-backup/mysite.tld.tar.gz: No such file or directory

All of the 11 sites that fail to backup are “Alias-Servers”. I’m not sure if that is just coincidence or not. Other Alias-Servers backup sucessfully. It looks like it’s always the same servers that fail to backup. I tried to just delete and recreate the failing servers, but that didn’t help.

dev/simfs on / type simfs (rw,relatime,usrquota,grpquota)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,relatime,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,relatime)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)

df -h
/dev/simfs 300G 105G 196G 35% /
tmpfs 2,0G 0 2,0G 0% /lib/init/rw
tmpfs 2,0G 0 2,0G 0% /dev/shm

Virtualmin: 3.89 gpl

Backup settings:
Features to backup: Backup all features
Backup destinations: SSH server
Additional destination options: Transfer each virtual server after it is backed up
Backup format: One file per server
Create destination directory?: Yes
Action on error: Continue with other features and servers
Backup level: Full (all files)

It makes no difference wheter the backup is scheduled or not.

we encounter the same problem.

Error message

Uploading archive to SSH server … … upload failed! myuser@x.x.x.x’s password:
/tmp/.webmin/17112008: No such file or directory
/xxxxxxxxx.tar.gz: No such file or directory

I am having the exact same problem. It happens consistently, with usually the same 2-3 domains (out of >10 total) failing to remotely back up via SSH in this exact manner. Oddly enough, it happens during every automatic backup, but whenever I tell Virtualmin to perform the backup (manually, apart from its schedule) every domain backs up without any errors.

The directories that don’t exist are named like:
Where [hostname] is the name of the server running Virtualmin (Pro) and performing the backups, and [X] is some 4-6 digit number

The user on the remote machine is not privileged (not authorized to perform commands as root via sudo). I intend to keep it this way because Virtualmin stores its password on the machine being backed up, making it extremely insecure. However, the ownership of /tmp/.webmin is root:root, and the permissions are 755 (rwxr-xr-x.), so it shouldn’t even be able to write to that directory in the first place (but it’s the way that Webmin/Virtualmin automatically set it up, so I’m inclined to think this is the way they should be).

Can anyone explain what is going on here?

Same problem here.
Is there a solution available?

A lot of backup related issues were resolved recently… you may want to make sure you’re using the most recent Virtualmin version. Are you using 3.98 there?