Ubuntu 26.04 Puts /tmp in RAM: Big CI Builds Run Out

What changed

Ubuntu now ships systemd's standard tmp.mount unit, which mounts /tmp as a RAM-backed file system: fast, wiped on reboot, and capped. The change happened in Ubuntu 24.10, so anyone moving from 24.04 to 26.04 meets it for the first time now.

On GitHub's standard runners that cap is about 7.8 GB, and the runner-images maintainers measured the runner user stopping at about 6.3 GB. On ubuntu-24.04 the same build had the whole root disk, around 90 GB free. That is why a job that passed for years fails as ubuntu-latest moves to 26.04.

Why a 9 GB build dies at 6 GB

1. Job starts on ubuntu-26.04. /tmp is a tmpfs: half the RAM, with a per-user quota.

1 / 5

Check your job

Add this step and look at the first word:

bash

findmnt -no FSTYPE,SIZE,OPTIONS /tmp

tmpfs with usrquota (a per-user quota) means your job has the RAM-backed /tmp. GitHub merged a fix that keeps /tmp on disk in the 26.04 image on 20 October 2026, but images built before it still have the tmpfs, so check rather than assume.

The fix

Either send temporary files to the runner's own temp directory, which is on disk, for every later step:

yaml

- run: echo "TMPDIR=$RUNNER_TEMP" >> "$GITHUB_ENV"

Go builds also read GOTMPDIR, so set that the same way: echo "GOTMPDIR=$RUNNER_TEMP" >> "$GITHUB_ENV". (You cannot write ${{ runner.temp }} in a job-level env: block; that block cannot see the runner context.)

Or, as the very first step, put /tmp back on the root disk, which is what the maintainers suggest:

yaml

- run: sudo systemctl mask tmp.mount && sudo umount -l /tmp

It has to come first, because files already in /tmp are hidden afterwards.

Running your own Ubuntu 26.04 servers? They do the same. The disk quota exceeded page covers servers too, and the ubuntu-latest 26.04 upgrade notes list everything else that changes on the new image.