/tmp: Explanation & Insights

A world-writable directory for short-lived scratch files, on most modern Linux systems backed by RAM and wiped on reboot or aged out by a scheduled cleanup.

What It Is

/tmp is the machine's scratch pad — the drawer everything on the system is allowed to open, toss something into, and forget about. When a program needs somewhere to park a file for a few seconds or a few minutes — a half-downloaded package, a lock file, the intermediate output of a compile, a socket two processes use to talk — it writes it here. Every user can create files in /tmp, every program can too, and the standing agreement is that nothing written here is precious. It is the one corner of the filesystem where "I'll clean it up later" is not a broken promise but the actual design.

The name is short for temporary, and the whole directory is built around that single word. Files here are expected to be short-lived, and the system takes that expectation literally: /tmp is emptied out from under you on a schedule, and on most machines it's wiped completely every time the box reboots. Write something here and walk away for a fortnight, and it will very likely be gone when you come back — not because anything failed, but because that's the deal you agreed to by choosing this drawer.

But ask what /tmp actually is on a modern server and the answer is not "a folder on the disk":

$ mount | grep -w "on /tmp"
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,nr_inodes=1048576,inode64)

That word tmpfs is the whole story. /tmp isn't on your disk at all — it's a tmpfs, a filesystem that lives in memory. When you write a file here, you are not writing to a spinning platter or a flash chip; you are writing to RAM, the same RAM your programs run in. The kernel dresses it up to look exactly like an ordinary directory — you ls it, you cd into it, you cp files around, and everything behaves — but underneath, there is no disk involved. You could physically unplug every drive in the machine and a write to /tmp would still land, because the drive was never part of the transaction. That is also, plainly, why a reboot wipes it clean: memory forgets everything the moment the power blinks, and /tmp is memory.

Why It Matters

Here is the practical consequence, and it catches sharp people out because it hides behind a familiar-looking number. Ask how full /tmp is and you get a perfectly ordinary-looking answer:

$ df -h /tmp
Filesystem      Size  Used Avail Use% Mounted on
tmpfs            16G  6.1G  9.5G  39% /tmp

Sixteen gigabytes, 39% full, nine and a half free. Reads like any disk. But there is no disk — that "16G" is a slice of RAM, and the default carve is half the machine's physical memory, which quietly tells you this box has about 32 GB of it. Every one of those 6.1 gigabytes sitting in /tmp is 6.1 gigabytes your applications can't use. The "free space" on this filesystem and the free space in your memory are the same pool, spent twice on one accounting sheet.

So when /tmp fills up, df will show you a filesystem running low and you'll reach for a bigger disk — and you'll be fixing the wrong machine. A full tmpfs is not a storage problem. It's memory pressure wearing a storage problem's clothes. The cure isn't a larger drive; it's more RAM, or a program told to stop writing so much, or (see below) a cleanup that never ran. If you take one thing from all this, take this: on a modern server, a /tmp that's filling up and a memory shortage are frequently the same event, described in two different vocabularies.

There's one lovely wrinkle that keeps this from being quite so tidy. A tmpfs isn't a pure RAM disk that pins every byte in memory forever — under real pressure, the kernel is allowed to push idle /tmp pages out to swap. So a file you wrote to your "in-memory" directory can, when things get tight, end up written to the disk after all — just to a different neighbourhood of it. Your temporary file was never guaranteed to touch the disk, and never guaranteed not to. It goes wherever the memory system finds it cheapest to keep.

And the classic trap, the one that bites every first-timer exactly once: a service that stashes something it actually needs in /tmp — a database socket, a cache it assumes will still be there, a PID file — and is then baffled when a reboot erases it, or when the nightly cleanup does. The directory did precisely what it always promised. The mistake was trusting a drawer labelled throw-away to hold something you wanted to keep. When that's you, the fix is usually /var — the home for state a program means to keep around.

/tmp vs /var/tmp: Two Kinds of Temporary

One directory over sits /var/tmp, and the difference between the two is one of those small, deliberate design decisions that repays a second look. Both are scratch space; both wear the same wide-open permissions. But they encode two genuinely different ideas of the word temporary.

/tmp is this session's scratch: throw-away, wiped on reboot, gone within days. /var/tmp is scratch I might still want tomorrow: it survives reboots, and it's kept around ten times longer. Look at the same box and the split is right there in the mount — /tmp is the tmpfs from above, but /var/tmp is on the ordinary disk-backed filesystem, so it outlives a power cycle the way /tmp never could:

$ ls -ld /var/tmp
drwxrwxrwt 14 root root 4096 Jul 17 09:31 /var/tmp

	`/tmp`	`/var/tmp`
Meaning	throw-away, this boot only	scratch worth keeping a while
Backing	usually RAM (tmpfs)	usually the disk
Survives a reboot?	no — wiped clean	yes
Aged out after	10 days	30 days
Good for	locks, sockets, tiny short-lived files	big scratch a long job needs across restarts

The rule of thumb writes itself. Small and short-lived, or something you'd want gone the instant the machine restarts? /tmp. Large — an unpacked archive, a multi-gigabyte intermediate — or something a long-running job needs to still find after a crash and a reboot? /var/tmp, because you do not want a 10 GB scratch file eating 10 GB of your RAM, and you do want it to survive the restart. Same idea, one directory apart, tuned for two different lifetimes.

Reading the Permissions

Take a proper look at /tmp itself and one character does a surprising amount of work:

$ ls -ld /tmp
drwxrwxrwt 79 root root 2920 Jul 17 10:02 /tmp

Read that permission string left to right. The leading d says directory. Then three groups of rwx — read, write, execute for the owner, the group, and everyone else — and all three are switched fully on. That's the 777 part, and on its own it would be alarming: everyone can create, write, and delete in here. A directory this open, on a shared machine, sounds like a recipe for one user quietly deleting another's files.

Except for that last character. Where you'd expect the final x for "everyone", there's a t instead: drwxrwxrwt. That t is the sticky bit, and on a directory it does one narrow, clever thing — it flips the delete rule. Normally, whether you can delete a file depends on your permission on the directory it lives in, not the file. In a wide-open directory like this, that would let anyone erase anyone's files. The sticky bit overrides it: with the bit set, you can only delete or rename a file if you own it (or you own the directory, or you're root). So /tmp gets to be genuinely world-writable — everybody can drop a file in — while still guaranteeing that only you can remove yours. Wide open for creating, locked down for deleting. It's a small, precise piece of security design, and it's the reason a directory this exposed isn't a free-for-all.

The full mode, written in octal, is 1777 — that leading 1 is the sticky bit, the 777 is the wide-open read/write/execute. You'll see it again in a moment in the cleanup config, and if you ever set up a shared scratch directory of your own, chmod 1777 (via chmod) is how you reproduce exactly this arrangement.

Note

The sticky bit protects against deletion and renaming, not reading. In a world-writable directory, other users can still list what's there and, if the individual files' own permissions allow it, read their contents. If a file in /tmp holds anything sensitive, its own permission bits are what protect it — the sticky bit on the directory only stops others from throwing it away.

How It Gets Cleaned Out

A reboot wipes /tmp for free, since it's memory. But servers can run for months, and something has to clear out the litter in the meantime — otherwise a box that never reboots would slowly fill its /tmp (and, remember, its RAM) with the forgotten leftovers of every program that ran since it booted. On a modern systemd machine, that housekeeping is a small scheduled job most admins have never once looked at, running quietly on their own servers right now:

$ systemctl status systemd-tmpfiles-clean.timer
● systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
     Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static)
     Active: active (waiting) since Tue 2026-07-07 08:54:52 CEST; 1 week 3 days ago
    Trigger: Fri 2026-07-17 19:17:25 CEST; 9h left
   Triggers: ● systemd-tmpfiles-clean.service

That's a systemd timer — a scheduled trigger, set to fire once a day — and active (waiting) means just what it says: loaded, idle, watching the clock, with Trigger: ... 9h left counting down to the next firing. When the moment lands it hands off to a service that walks the temporary directories and sweeps out anything that's sat untouched too long. What counts as "too long" isn't baked into the code — it's written out in a plain file you can open yourself:

$ cat /usr/lib/tmpfiles.d/tmp.conf
# Clear tmp directories separately, to make them easier to override
q /tmp 1777 root root 10d
q /var/tmp 1777 root root 30d

Two lines, and they say everything. Each names a directory, the mode it should have (1777 — there's the sticky bit again), the owner and group, and finally the age limit: anything in /tmp untouched for 10 days gets swept away; in /var/tmp, the window is 30 days. That's the exact source of the "10 days / 30 days" split from the table earlier — not folklore, just this file. Change the number here (or, better, drop an override in /etc/tmpfiles.d/) and you change how long your scratch files survive. It's a rare thing in system administration: a piece of behaviour everyone relies on, sitting in the open in two readable lines, doing exactly what it says.

How I Inspect It

The moves I make, in the order I make them, when I want to know what /tmp really is on a machine I've just met:

# Is /tmp on RAM or on the disk? (look for 'tmpfs')
mount | grep -w "on /tmp"

# How much room — and remember, on tmpfs that room is RAM
df -h /tmp

# The permissions, sticky bit and all
ls -ld /tmp /var/tmp

# When does the cleanup next run?
systemctl status systemd-tmpfiles-clean.timer

# What are the age-out rules?
cat /usr/lib/tmpfiles.d/tmp.conf

# What's actually eating the space right now?
du -sh /tmp/* 2>/dev/null | sort -rh | head

The one I reach for most is the first. Before I reason about anything to do with /tmp — a disk-full alarm, a service losing its state, a memory number that won't add up — I want to know whether I'm looking at RAM or a disk, because the whole diagnosis forks on that single answer.

Gotchas

A full /tmp may be a memory problem, not a disk problem. On tmpfs, df shows a filling filesystem, but the thing running out is RAM. Before you provision a bigger disk, check whether /tmp is a tmpfs — if it is, you're chasing memory, not storage. It can even be the hidden cause behind a disk full-shaped alert that no disk can fix.
Nothing in /tmp survives a reboot on a tmpfs system — it's memory, and memory forgets. If a program keeps something it truly needs here, that's a bug in the program, and the fix is /var.
Even without a reboot, files vanish after ~10 days. The systemd-tmpfiles cleaner ages them out on a schedule. A file you left a fortnight ago being gone is the system working, not failing.
/var/tmp is not the same as /tmp. It's on the disk, it survives reboots, and it's kept for 30 days. Reach for it when scratch is large or needs to outlive a restart — never assume the two behave alike.
World-writable is not world-deletable. Thanks to the sticky bit, other users can create files alongside yours but can't remove yours. If you want a shared scratch directory to behave this way, chmod 1777 is the incantation — and if you ever find a shared temp directory missing its sticky bit, that's a real security hole worth fixing.
Don't put anything secret in /tmp unprotected. The directory is readable by everyone; only the files' own permissions guard their contents. A predictably-named temp file in a world-readable directory is a classic way for one program to leak to another.

History and Philosophy

/tmp is one of the oldest directories in Unix — it was there almost before there was a "there", back when a filesystem layout was a handful of directories a single person could hold in their head. Scratch space is such a basic need that /tmp predates almost everything we now think of as standard, and it's stayed put through every reorganisation since. What's genuinely strange about it is that a directory this old and this universal has quietly meant three different implementations of "temporary" over the decades: first a plain directory on the disk, cleared by boot scripts; then, once Linux grew a real tmpfs in the 2.4 kernel around 2001, an optional slab of memory; and today, on most desktop distributions, memory by default. Same directory, same promise, three completely different machines underneath — and almost no program that uses it ever had to notice the ground shifting.

Then there's that little t, which carries a piece of history most people who type chmod 1777 never learn. The sticky bit is old — it goes back to the Fifth Edition of Unix in 1974, Thompson and Ritchie's work — but it originally did something with nothing to do with deleting files. Back then, setting the sticky bit on a program told the kernel to keep that program's code "stuck" in swap after it finished running, so the next launch could pull it back fast instead of re-reading it from a slow disk. That's literally why it's called sticky: the program stuck around in memory. Modern virtual memory made that trick pointless and it was quietly retired — but the bit was still sitting there in the permission mode, unused, so it got handed a brand-new, unrelated job: guarding deletions in shared directories. The name is a fossil. It describes a behaviour no living system performs, on a bit that now does something else entirely — and every drwxrwxrwt you'll ever see is quietly carrying that half-century-old ghost of a name for a feature nobody's used since disks were the size of washing machines.

The deeper philosophy is worth naming, because it's easy to miss under something so mundane. /tmp is the system admitting, structurally, that not everything is worth keeping. A computer that treated every byte as precious would drown in its own litter; the genius of a dedicated throw-away drawer, swept on a timer and vaporised on reboot, is that it lets programs be careless on purpose, in exactly one sanctioned place. Most of the filesystem is about remembering. /tmp is the one part built around the equal and opposite art of forgetting.

Cheat Sheet

# --- What is it, really ---
mount | grep -w "on /tmp"        # tmpfs (RAM) or a real disk?
df -h /tmp                        # space — but on tmpfs, that space is RAM
ls -ld /tmp /var/tmp             # permissions + the sticky bit (drwxrwxrwt)

# --- Who's using it ---
du -sh /tmp/* 2>/dev/null | sort -rh | head   # biggest offenders
ls -la /tmp                       # what's actually in there

# --- The cleanup ---
systemctl status systemd-tmpfiles-clean.timer  # when it next runs
cat /usr/lib/tmpfiles.d/tmp.conf               # the age-out rules (10d / 30d)
systemd-tmpfiles --clean                        # run the cleanup by hand, now

# --- Making your own shared scratch dir ---
mkdir /srv/scratch
chmod 1777 /srv/scratch          # world-writable, but delete-protected

# --- Change /tmp's size (if it's a tmpfs), live ---
mount -o remount,size=8G /tmp    # temporary; persist it in /etc/fstab

Pro Tip

If a service keeps losing state across restarts, check whether it's writing under /tmp. It's an easy mistake — /tmp is always there and always writable — but on a tmpfs box every reboot is a clean slate, and the daily cleaner erases anything idle for ten days even between reboots. Anything that must persist belongs in /var, not here.