"No space left on device" on /tmp

Hi,

I periodically run a backup command to create a gzip of some files on the server in /tmp and then downloading it. It works like this:

flyctl ssh console -C "tar -czf /tmp/wp-content-$TIMESTAMP.tar.gz -C /var/www/html wp-content";
flyctl ssh sftp get /tmp/wp-content-$TIMESTAMP.tar.gz ./

This has worked well for months, but recently I’m seeing an error on the first line:

Connecting to fdaa:0:efa6:a7b:9d34:9e7f:4e1b:2...
gzip: stdout: No space left on device
tar: /tmp/wp-content-2026-04-18.tar.gz: Wrote only 2048 of 10240 bytes
tar: Child returned status 1
tar: Error is not recoverable: exiting now

From this post it seems I should have 8GB of space.The gzip would be way less than that, so I don’t know why it fails after writing only 2KB. I’m not seeing anything useful in logs, just that I’ve sshed into the machine.

Any help in interpreting this error would be appreciated!

Hi… I think that’s actually just the buffer (or pipe) size. I tried a similar tar -czf operation over here, on a volume that was deliberately too small, and it likewise said Wrote only 6144 of 10240 bytes, even though it had really already written 86016 bytes to disk by that point.

I would SSH in and use df -h to find the actual amount of space on the root volume:

$ fly ssh console
# cd /tmp
# df -h .

Possibly you have a WordPress plugin or similar that’s been creating temporary files and not cleaning them up lately…

Hope this helps!

It may also be worth checking if /tmp has been independently mounted, and thus has a different total file size limitation to what you’re expecting. I think you can just do mount in a console to find all your mounts; post them here, in a code block, if you want advice on that.

Of course you can attach a volume at /tmp if you want a larger allocation, though I agree with @mayailurus that clearing the space down may be the easiest solution. You may wish to limit this to older files, in case WordPress is still using some of them.

Thank you both! Good idea to ssh into it manually and check what’s taking up the space. It turns out my /tmp directory is full of my temporary backup files over a long time and they aren’t purged frequently (or at all) as I hoped.

Aha, good find. On a Linux server or desktop Linux, auto-clearing /tmp would probably be done on a system/root cron. However, for most Docker images, you may find that they’re based on Busybox, and thus bells-and-whistles are not included. You can of course add that, if you wish.