When /tmp fills a 1‑GB VPS in 15 minutes – how a simple tmpfs mount stops crashes

A 1‑GB VPS that dies in 15 minutes: the /tmp overflow problem

When a 1‑GB VPS runs a handful of services that write temporary files—apt‑get, pip, Docker, or even a simple web server—the /tmp directory can fill up faster than you think. Once the filesystem is full, many processes abort, the kernel starts killing tasks, and the machine can become unresponsive. The fix is surprisingly simple: mount /tmp as a tmpfs so it lives in RAM instead of on the disk.

Why the disk‑backed `/tmp` is a bad fit for small VPS

No swap – Most minimal VPS images disable swap to keep the footprint small. When /tmp is on disk, a full /tmp means the kernel has no place to move pages, so it has to kill processes.
Disk I/O bottleneck – Writing to a small SSD or a shared block device can saturate I/O, especially under concurrent builds or package installations.
Persistence risk – A reboot wipes /tmp, but if a service expects a file to survive a restart, it will fail.

On a 1‑GB VPS, the default /tmp size is the same as the root filesystem, so a few megabytes of temporary data can quickly consume the entire disk.

The tmpfs solution

tmpfs is a memory‑backed filesystem. It behaves like a regular directory but stores data in RAM (and swap if enabled). It is ideal for temporary data that does not need persistence.

Quick one‑off mount

sudo mount -t tmpfs -o size=512M,mode=1777 tmpfs /tmp

size=512M caps the maximum memory used. Adjust to your RAM; on a 1‑GB VPS, 512 MiB leaves enough headroom for the OS.
mode=1777 gives the standard world‑writable permissions.
After this, df -h /tmp will show a 512 MiB filesystem.

Make it permanent

Add an entry to /etc/fstab:

tmpfs   /tmp   tmpfs   defaults,noatime,mode=1777,size=512M   0   0

Now the mount persists across reboots. If you prefer systemd’s unit system, create /etc/systemd/system/tmp.mount:

[Unit]
Description=Temporary Directory

[Mount]
What=tmpfs
Where=/tmp
Type=tmpfs
Options=mode=1777,size=512M

[Install]
WantedBy=local-fs.target

Then enable it:

sudo systemctl daemon-reload
sudo systemctl enable --now tmp.mount

Security tweaks that go hand‑in‑hand with tmpfs

noexec – Prevents execution of binaries from /tmp, a common vector for local privilege escalation. Add noexec to the mount options.
nosuid – Stops set‑UID binaries from gaining extra privileges. Also add nosuid.
nodev – Disallows device files. Add nodev if you want to be extra strict.

Example:

tmpfs   /tmp   tmpfs   defaults,noatime,mode=1777,size=512M,noexec,nosuid,nodev   0   0

These flags are recommended by the Linux Security Hardening guidelines and are supported on all mainstream kernels (see the kernel documentation at https://www.kernel.org/doc/html/latest/filesystems/tmpfs.html).

What about services that need persistent temp files?

/var/tmp is the canonical place for temporary data that must survive reboots. Most distributions already mount /var/tmp on the root filesystem, so it remains disk‑backed. If you need a memory‑based /var/tmp, you can create a separate tmpfs mount, but be mindful of the memory trade‑off.

Alternatively, many services expose a RuntimeDirectory or PrivateTmp option in their systemd unit files. For example, the Apache unit can be tweaked:

[Service]
PrivateTmp=true

This gives Apache its own isolated /tmp, backed by the system’s default /tmp mount (now a tmpfs). This isolation is often enough to keep the service running smoothly while still protecting the rest of the system.

TAGS: linux, tmpfs, vps, security

linux open-source

A 1‑GB VPS that dies in 15 minutes: the /tmp overflow problem

Why the disk‑backed /tmp is a bad fit for small VPS