Backup and restore failures "no space left on device"

Sorry, but I don’t think this is the correct solution to the original issue of /tmp potentially being mounted from a RAM disk. I like the ideal of creating a common default_webmin_temp_dir function for returning the base temp directory, but the fix you checked in may just cause the same problem if /var/tmp is on a RAM disk.

Also, this change would mean that on upgrade the temp file location would unexpectedly change for existing installs which is not great for users. For example, what if the user had mounted /tmp from a separate filesystem in order to ensure plenty of space for backups?

For this reason I’ve reverted the change. The right solution would be for new installs only to detect if /tmp is mounted from a RAM disk and if /var/tmp exists, to set tempdir in /etc/webmin/config to /var/tmp/.webmin

1 Like

Sorry, of course Im not involved in the internal workings here. But to me it sounds risky to

  1. Use any tmp folder (/tmp or /var/tmp) because it might be a ramdisk
  2. Use a hidden folder (why should it be hidden?)

In my current setup I created /tmp-webmin/tmp to make sure it does not interfere with any other structures. /var/webmin/tmp also sounds acceptable to me.

For consistency reasons I would not want different temp folder paths on different server setups.

1 Like

Yes, there were two separate commits made intentionally. One was to refactor the code to return a base temp directory, and the other was to actually use it.

Well okay, there’s a chance of that, I agree. Still, it wouldn’t be hard for a user to fix by adding an option to use a specific temp directory.

There’s also a chance that /var/tmp could be mounted on a RAM disk—though I don’t think I’ve ever seen real systems set up that way.

Got it. That will make things a bit more difficult, and I was trying to avoid that.

Also, there doesn’t seem to be a clean solution to this as far as I can tell.

For example, what if /var is a separate partition with limited space? Are we going to check for that too?

And probably not only the new installs, but rather the ones without a custom temp directory set?

I don’t like changing behavior on existing systems as that could cause confusing behavior for users. Best we can do I think is at new install time figure out which temp dir is best based on available disk space, and if it’s not /tmp switch to the better path. Or alternately display a warning on the dashboard if the temp dir is on a filesystem with low disk space?

I think for Webmin users that would be a better option. Yet for Virtualmin user, I’d rather make it work out of the box in the Virtualmin Config.

Agreed, so we should just select a sensible temp dir at Virtualmin install time based on free space. Webmin’s mount module has APIs for getting filesystems and disk space that can be used.

Alright, will do for the Virtualmin Config. And, will you add an alert message to the dashboard in Webmin with a link to the “Webmin Configuration → Advanced” page?

Sure, will do!

@Ilia check out Add a warning if the temp files directory is less than 10 MB · webmin/webmin@38cae2f · GitHub

@Jamie, I checked, thanks. It seems there was a typo, though. See my patch to fix it.

Yet, I do not think this is the best we can do.

First, this message cannot be dismissed.

And second, we do not know what is small and what is not for a user.

We assume that 10GB is small, but that will almost never be right for everyone.

I think the right approach is to make the alert dismissible and, more importantly, check if the temp directory is memory-backed.

I don’t think the committed code as it is now is good enough.

I’m sure it will irritate a lot of people.

The current threshold is 10 MB, not 10 GB .. so it only triggers on really small filesystems.

That said, do we know of specific Linux distros that create a small /tmp by default? And if so, how small?

I can also add a separate check for /tmp being on a RAM disk.

What’s the point then? There are no filesystems that small!?

The problem wasn’t a small /tmp. The problem was that some distros use RAM disk for /tmp.

Yes, this check would be useful.

Ok, I’ve added a change for this.

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