Ubuntu 26.04 · troubleshooting

disk quota exceeded writing to /tmp

Ubuntu 26.04 mounts /tmp in RAM, limited to half the memory with a per-user quota, so writing several gigabytes there fails while the disk is nearly empty. It hits GitHub's ubuntu-26.04 runners (fix merged 20 Oct 2026, not yet in an image) and servers upgraded to 26.04. Send large temporary files to the disk with TMPDIR, or put /tmp back on disk.

First published 21 Oct 2026

New to this? Read what is actually happening first, then come back to the steps.

On this page · 10 sections

Before you start

A shell on the machine, or the ability to add a step to the CI job.
sudo, if you choose to move /tmp back to the disk.

Run this first

step 1 of 2

findmnt -no FSTYPE,SIZE,OPTIONS /tmp

Look for tmpfs, a size near half the RAM, and usrquota

Shows whether /tmp is a tmpfs and how big it is.

Work out which cause you have

A few questions to narrow the list. Every answer ends in a command that confirms or rules the cause out — this cannot see your cluster, so nothing here is a certainty until you have checked.

Narrow it down

0 answered · nothing is sent anywhere

Where does the build run?

Cause space

2 of 2 still possible

A GitHub ubuntu-26.04 runner image with /tmp in RAMCommon
A server or VM upgraded to Ubuntu 26.04Common

Nothing ruled out yet. Answer the question above and the branches your answer eliminates will strike through here.

Check it with a tool

What changes on ubuntu-latest 26.04

Or diagnose it manually

In this order. The first command usually contains the whole answer.

Step 1
```
findmnt -no FSTYPE,SIZE,OPTIONS /tmp
```
Shows whether /tmp is a tmpfs and how big it is.
Look for tmpfs, a size near half the RAM, and usrquota
Step 2
```
du -sh /tmp 2>/dev/null; df -h /tmp /
```
Compares what is in /tmp with the space actually free on disk.
Look for /tmp nearly full while / has room

Every cause, and how to fix it

Ordered by how often each one turns out to be the answer.

A GitHub ubuntu-26.04 runner image with /tmp in RAM

Common

Jobs on ubuntu-26.04, and on ubuntu-latest once it moves there, get /tmp as a tmpfs in images built before the fix of 20 Oct 2026. Large builds that pass on ubuntu-24.04 fail at a few gigabytes.

Confirm

findmnt -no FSTYPE,SIZE,OPTIONS /tmp
df -hT /tmp /

tmpfs with usrquota for /tmp, and a root disk with tens of gigabytes free

Fix

Send temporary files to the work disk: as the first step, run echo "TMPDIR=$RUNNER_TEMP" >> "$GITHUB_ENV", which applies to every later step. (A job-level env: cannot use the runner context.) Go builds also honour GOTMPDIR.
Or make /tmp use the root disk again, as the first step of the job: sudo systemctl mask tmp.mount && sudo umount -l /tmp. It must come first, because files already in /tmp are hidden afterwards.
Or pin runs-on: ubuntu-24.04 until an image with the fix reaches your runners, then remove the pin.

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

First step of the job; the runner-images maintainers checked that a 9G write passes afterwards.

A server or VM upgraded to Ubuntu 26.04

Common

Any Ubuntu 26.04 machine, including one upgraded in place from 24.04, now mounts /tmp as a tmpfs at boot. Build agents, backup jobs and database dumps that wrote large files to /tmp start failing, and the RAM they use competes with your services.

Confirm

findmnt -no FSTYPE,SIZE,OPTIONS /tmp
systemctl is-enabled tmp.mount

tmpfs, and tmp.mount not masked

Fix

Point large temporary work at disk: set TMPDIR (or the tool's own setting) to a directory on disk, such as /var/tmp or one per service.
Or opt the machine out: sudo systemctl mask tmp.mount, then reboot. /tmp is then a directory on the root file system again.

Understanding it properly

Skip this if you are mid-incident — the working part of the page is above. Worth reading afterwards, because understanding the mechanism is what stops the next one.

In plain terms

Programs keep scratch files in /tmp. Until now on Ubuntu LTS that folder was on the main disk, so it could hold as much as the disk. From Ubuntu 26.04 it lives in memory instead, which is faster and is wiped on reboot, but it can only hold about half of the machine's RAM, and one user can fill only part of that. A big build that writes more than that gets "disk quota exceeded" even though df shows plenty of free disk space.

Words used on this page

tmpfs: A file system held in memory (and swap). Fast, emptied on every reboot, and limited by a size you set.
tmp.mount: The systemd unit that mounts /tmp as a tmpfs. Ubuntu ships the upstream one by default from 24.10, so LTS users meet it in 26.04.
EDQUOT: The error code behind "disk quota exceeded": a per-user limit was reached, not the disk.
TMPDIR: The environment variable most programs read to decide where temporary files go, instead of /tmp.

What is actually happeningadvanced

Ubuntu now ships systemd's upstream tmp.mount unit, so /tmp is a tmpfs by default (changed in Ubuntu 24.10, first in an LTS with 26.04). The unit mounts it with size=50% of RAM, a limit of about a million files, and a per-user quota.

On a GitHub standard runner that is about 7.8G, and the runner-images maintainers measured the runner user stopping at about 6.3G. The 24.04 image kept /tmp on the root disk with roughly 90G free, so the same build passes there.

GitHub merged a fix that masks tmp.mount in the 26.04 image on 20 Oct 2026 (runner-images #14814). Images built before it, including 20261018, still have the tmpfs; findmnt in the job tells you which one you got.

Containers started from an ubuntu:26.04 image do not run systemd, so their /tmp is ordinary container storage; this is about hosts and VMs.

systemd's own guidance is that /tmp is for small, size-bounded files and everything else belongs in /var/tmp or in $TMPDIR.

How to tell this is your problemsignals

Where	What you see
Build output	compile: writing output: write $WORK/b4822/_pkg_.a: disk quota exceeded
Any tool writing to /tmp	disk quota exceeded, or No space left on device, after a few gigabytes
df -h /	Plenty of free space on the root disk at the same moment
findmnt /tmp	tmpfs … size=…,usrquota

How to know it is actually fixed

The build that failed completes.
With TMPDIR set, mktemp prints a path under the new directory, not /tmp.
After masking and reboot (or the umount on a runner), findmnt -no FSTYPE /tmp prints nothing, because /tmp is no longer a mount point.

Stopping it happening again

Have tools that write gigabytes use TMPDIR or their own temp setting rather than relying on /tmp being large.
Before moving CI to ubuntu-26.04 or ubuntu-latest, run the biggest build once on 26.04 and add findmnt /tmp to the job's diagnostics.

Security considerations

Do not point TMPDIR at a world-writable directory that you create by hand without the sticky bit; use a directory owned by the user that runs the job, such as the runner's own temp directory.
Masking tmp.mount on a shared server gives up the per-user quota, which stopped one user from filling /tmp for everyone. On a single-purpose build machine that is usually fine; on a shared host, prefer TMPDIR per job.

Sources

Behaviour described here is drawn from official documentation. Where a figure could not be confirmed on an official page it is attributed in the text rather than stated as canonical.

Did this get you to an answer?

No text box on purpose — please do not paste production logs anywhere

Something wrong or out of date? Report it