/tmp is the one directory on a Linux system explicitly designed around the idea that its contents do not matter in the long run. Understanding how it behaves, and specifically what “temporary” actually guarantees, matters more than it first appears, because assuming the wrong thing about /tmp is a classic way to lose data unexpectedly.

What /tmp is actually for

Any program that needs a scratch file, somewhere to stage data mid-process, write a lock file, or hold a temporary buffer, can write to /tmp without needing to create or manage its own dedicated directory:

ls -la /tmp
# drwxrwxrwt  12 root root  4096 Jul  9 09:00 .

# See what's currently sitting in /tmp
ls -la /tmp

# Check how it's mounted
findmnt /tmp

The defining characteristic of /tmp is that nothing stored there is expected to survive indefinitely. Applications that use it correctly treat it as fully disposable: if a file in /tmp disappears mid-session, a well-written program should regenerate it rather than fail outright.

Why /tmp gets cleared, and when

The exact clearing behavior depends heavily on the distribution, but two common mechanisms exist:

# Mechanism 1: tmpfs, cleared automatically on every reboot
# because it exists only in RAM
findmnt /tmp
# TARGET SOURCE FSTYPE OPTIONS
# /tmp   tmpfs  tmpfs   rw,nosuid,nodev

# Mechanism 2: systemd-tmpfiles, a scheduled cleanup job
# that deletes files older than a configured age
cat /usr/lib/tmpfiles.d/tmp.conf
# d /tmp 1777 root root 10d
# (the 10d means files untouched for 10 days get removed)

# Manually trigger a cleanup pass to see what it would remove
sudo systemd-tmpfiles --clean

If /tmp is mounted as tmpfs, a filesystem type that lives entirely in RAM rather than on disk, everything inside it vanishes the instant the machine reboots or loses power, because RAM does not retain its contents without electricity. If /tmp is instead a regular directory on the disk-backed root filesystem, a periodic job like systemd-tmpfiles handles cleanup on a schedule instead, deleting anything that has not been accessed in a configured number of days, commonly ten.

The performance case for tmpfs

Mounting /tmp as tmpfs is popular specifically because RAM is dramatically faster than even the fastest SSD:

# Check current /tmp size limit if mounted as tmpfs
df -h /tmp

# A typical fstab entry configuring /tmp as tmpfs with a size cap
# tmpfs /tmp tmpfs defaults,noatime,size=2G 0 0

Compilers, package managers, and build systems often create and delete large numbers of small temporary files during their work. Doing that on a RAM-backed filesystem instead of disk avoids wearing out an SSD with constant writes and speeds up anything that is bottlenecked on temporary file I/O. The tradeoff is that tmpfs consumes RAM proportional to how much data is stored in it, so a size limit is usually configured to prevent a runaway process from filling all available memory.

/tmp vs /var/tmp

/tmp/       # cleared aggressively: often every reboot, or after ~10 days
/var/tmp/   # cleared gently: expected to survive reboots, cleaned after ~30 days

The distinction exists for software that genuinely needs temporary scratch space to survive a planned reboot, something in the middle between “fully disposable” and “permanent.” A package manager mid-download, for instance, might use /var/tmp so that a scheduled maintenance reboot does not force it to restart the download from scratch. Software should choose between the two based on how long it actually needs the data to persist, not simply default to whichever is more convenient.

The sticky bit on /tmp

ls -ld /tmp
# drwxrwxrwt  12 root root  4096 Jul  9 09:00 /tmp

That trailing t in the permission string is the sticky bit, and it is essential to how /tmp functions safely as a shared, world-writable directory. Without it, any user able to write to /tmp (which is every user, by design) could also delete or rename any other user’s files sitting in /tmp, since standard Unix permissions only check the directory’s write permission for deletion, not the individual file’s owner.

# The sticky bit restricts deletion to:
# - the file's own owner
# - the directory's owner (root, in this case)
# - a user with root privileges

# Set the sticky bit manually on a shared directory
chmod +t /some/shared/directory

# Verify it's set
ls -ld /some/shared/directory

This single permission bit is what makes it safe for /tmp to be world-writable at all. Every user can create files, but only the file’s own creator (or root) can delete them, preventing one user’s temporary files from being tampered with or removed by another.

Practical guidance for using /tmp

# Create a uniquely named temporary file safely, avoiding collisions
mktemp
# /tmp/tmp.XXXXXXXXXX

# Create a uniquely named temporary directory
mktemp -d
# /tmp/tmp.XXXXXXXXXX

# Use a template for a more identifiable name
mktemp /tmp/mybuild.XXXXXX

Using mktemp instead of hardcoding a filename like /tmp/output.txt avoids a class of bugs and security issues where two processes (or two runs of the same script) collide on the same filename, or where a malicious local user predicts a temporary filename in advance and creates it first with unexpected permissions.

Frequently Asked Questions

What is the /tmp directory used for?

The /tmp directory is designated scratch space for temporary files that programs create while running and no longer need afterward. Applications use it for things like lock files, temporary download buffers, session data, and intermediate files during a build or conversion process. Any user or process can generally write to /tmp, and its contents are not expected to persist long-term.

Is /tmp cleared automatically and when?

On most modern distributions, yes. Many systems clear /tmp on every reboot, especially when it is mounted as tmpfs (a RAM-backed filesystem). Others use a scheduled cleanup job, such as systemd-tmpfiles or a cron job, that deletes files older than a certain age (commonly 10 days) regardless of reboots. The exact behavior depends on the distribution and its configuration, but the universal rule of thumb is: never store anything in /tmp that you cannot afford to lose at any moment.

What does it mean that /tmp is mounted as tmpfs?

tmpfs is a filesystem type that stores its contents in RAM (and swap, if needed) instead of on a physical disk. Many modern distributions mount /tmp as tmpfs by default, which makes reading and writing to /tmp extremely fast since it never touches the disk, but also means everything in /tmp disappears immediately on reboot or power loss, since RAM contents do not survive a restart. You can check whether this applies to your system with findmnt /tmp.

What is the difference between /tmp and /var/tmp?

/tmp is for short-lived temporary files that are safe to lose on reboot, and on many systems is wiped clean at every restart. /var/tmp is also for temporary files, but ones that are expected to persist across a reboot, cleared instead on a longer schedule (often 30 days) by a periodic cleanup job rather than at every restart. Software that needs scratch space surviving a restart, such as a long-running download resumed after a planned maintenance reboot, is supposed to use /var/tmp instead of /tmp.

Why do permissions on /tmp look unusual, like drwxrwxrwt?

The final t in that permission string is the sticky bit. /tmp is world-writable (every user can create files there) because many different users and processes need to write temporary files to the same shared directory. Without the sticky bit, any user could delete or rename any other user’s files in /tmp, which would be a serious problem on a multi-user system. The sticky bit restricts deletion so that only the file’s owner, the directory owner, or root can remove a given file, even though everyone can create new ones.

Can I safely delete everything in /tmp manually?

Generally yes, though with one caveat: deleting a file that another running process currently has open can cause that process to error or behave unexpectedly, since it may still be actively reading or writing to it. It is safer to let the system’s own cleanup mechanism (tmpfiles.d rules or a reboot) handle it, or to only delete files that are clearly old and unrelated to anything currently running, rather than blanket-deleting the entire directory while the system is live.