When Temporary Files become a Memory Problem

Using disk rather than RAM for temporary files.

A small EC2 instance can fill a temporary directory in RAM while its EBS volume is mostly empty.
AWS
Linux
Published

2026/08/27

There’s a rather perplexing kind of disk-full error on small EC2/Ubuntu instances: df -h says the EBS volume has plenty of room, but a program writing to /tmp falls over. Why? Because /tmp isn’t actually on disk: it lives in RAM as a tmpfs file system. This is sensible when fast, disposable temporary storage is the aim. It’s inconvenient when you want to do something that relies on being able to temporarily dump some chunky files into /tmp.

The Problem

Run df to see mounted file systems.

df -h

The abridged output.

Filesystem      Size  Used Avail Use% Mounted on
/dev/root       6.7G  2.1G  4.6G  31% /
tmpfs           225M     0  225M   0% /tmp

It’s nominally a 8 GiB drive, of which 6.7 GiB is allocated to the root file system, where there’s still plenty of space. The /tmp directory is mounted via tmpfs, which means that it’s not on disk at all, but rather exists in RAM. It’s only 225 MiB, generally sufficient, but in some circumstances not enough!

RAM is already constrained on small EC2 instances: although it’s only 225 MiB, it’s 225 MiB that could be fruitfully used elsewhere. To illustrate the point, this is what I initially get from free -h:

               total        used        free      shared  buff/cache   available
Mem:           448Mi       202Mi        59Mi       1.8Mi       221Mi       245Mi
Swap:             0B          0B          0B

Then I created a 100 MiB file in /tmp using dd and checked again.

               total        used        free      shared  buff/cache   available
Mem:           448Mi       303Mi        11Mi       101Mi       268Mi       145Mi
Swap:             0B          0B          0B

The used RAM jumped up by the size of the file. ☹️ Not cool.

The Fix

Mounting /tmp as a tmpfs is controlled by the tmp.mount unit in systemd. Mask that unit so that it’s not run when the system starts.

sudo systemctl mask tmp.mount
Created symlink '/etc/systemd/system/tmp.mount' → '/dev/null'.

Restart the system so that the change takes effect (masking won’t unmount the current /tmp).

sudo reboot

When it comes back online, reconnect and run df -h.

Filesystem      Size  Used Avail Use% Mounted on
/dev/root       6.7G  2.1G  4.6G  31% /

There’s no /tmp file system because now it’s just another directory under /. This gives temporary files room to grow without taking a bite out of the instance’s already limited memory. The trade-off is plain: /tmp is no longer RAM-backed and it can now fill the root volume. Keep an eye on it and clean up jobs which leave substantial data behind.

If a later workload genuinely benefits from a memory-backed /tmp, reverse the change.

sudo systemctl unmask tmp.mount