{"id":2177,"date":"2026-04-11T09:39:24","date_gmt":"2026-04-11T06:39:24","guid":{"rendered":"https:\/\/computingforgeeks.com\/?p=2177"},"modified":"2026-04-11T09:40:08","modified_gmt":"2026-04-11T06:40:08","slug":"mount-tmp-separate","status":"publish","type":"post","link":"https:\/\/computingforgeeks.com\/mount-tmp-separate\/","title":{"rendered":"Configure \/tmp on a Separate Partition or tmpfs on Linux"},"content":{"rendered":"\n

Putting \/tmp<\/code> on its own filesystem isolates temporary files from the root volume and lets you mount it with options the rest of the system shouldn’t have. The classic recipe uses a dedicated disk partition. The modern recipe uses a tmpfs (RAM-backed) mount managed by systemd. Both are valid, and each is the right choice in a different situation. This guide walks through both on Ubuntu 24.04 LTS (following an in-place upgrade from 22.04<\/a>) and Debian 13.<\/p>\n\n\n\n

The operational benefits are the same either way: crashes, runaway processes, or hostile code dumping data into \/tmp<\/code> can never fill the root filesystem, the mount carries nosuid<\/code>, nodev<\/code>, and noexec<\/code> so attackers can’t stage executables there, and the directory is cleared on every boot without you needing to write a cleanup script.<\/p>\n\n\n\n

Verified: April 2026<\/strong> on Ubuntu 24.04.4 LTS with kernel 6.8.0-101-generic using systemd’s tmp.mount<\/code> unit<\/em><\/p>\n\n\n\n

Approach 1: Mount \/tmp as tmpfs (recommended for most servers)<\/h2>\n\n\n\n

tmpfs stores everything under \/tmp<\/code> in RAM, falling back to swap if pressure forces it. It’s fast, it clears itself on every boot automatically, and there’s no disk partition to plan. The only cost is that files in \/tmp<\/code> now compete for RAM with everything else.<\/p>\n\n\n\n

Ubuntu 24.04 does not enable tmp.mount<\/code> by default. Check whether a unit exists:<\/p>\n\n\n\n

findmnt \/tmp\nsystemctl cat tmp.mount 2>&1 | head -5<\/code><\/pre>\n\n\n\n
On a stock 24.04 cloud image you’ll see that \/tmp<\/code> is not a separate mount and there’s no unit file yet:<\/p>\n\n\n\n
No files found for tmp.mount.<\/code><\/pre>\n\n\n\n
Drop a unit file into \/etc\/systemd\/system\/tmp.mount<\/code> and enable it. The unit below mirrors the one shipped on systems that do enable it by default, sized to use up to half the physical memory:<\/p>\n\n\n\n
sudo vi \/etc\/systemd\/system\/tmp.mount<\/code><\/pre>\n\n\n\n
Paste in the full unit:<\/p>\n\n\n\n
[Unit]\nDescription=Temporary Directory (\/tmp)\nDocumentation=man:hier(7) man:tmpfs(5)\nConditionPathIsSymbolicLink=!\/tmp\nDefaultDependencies=no\nConflicts=umount.target\nBefore=local-fs.target umount.target\nAfter=swap.target\n\n[Mount]\nWhat=tmpfs\nWhere=\/tmp\nType=tmpfs\nOptions=mode=1777,strictatime,nosuid,nodev,size=50%,nr_inodes=1m\n\n[Install]\nWantedBy=local-fs.target<\/code><\/pre>\n\n\n\n
Reload systemd and enable the mount. The unit activates immediately and persists across reboots:<\/p>\n\n\n\n
sudo systemctl daemon-reload\nsudo systemctl enable --now tmp.mount<\/code><\/pre>\n\n\n\n
Confirm the mount is active and check the options:<\/p>\n\n\n\n
findmnt \/tmp\ndf -hT \/tmp<\/code><\/pre>\n\n\n\n
The output reports the filesystem type as tmpfs and the size is capped at half the machine’s RAM:<\/p>\n\n\n\n
TARGET SOURCE FSTYPE OPTIONS\n\/tmp   tmpfs  tmpfs  rw,nosuid,nodev,size=1007612k,nr_inodes=1048576,inode64\nFilesystem     Type   Size  Used Avail Use% Mounted on\ntmpfs          tmpfs  984M     0  984M   0% \/tmp<\/code><\/pre>\n\n\n\n
nosuid<\/code> stops set-UID binaries from running with their owner’s privileges, nodev<\/code> blocks device node creation, and size=50%<\/code> caps the mount at half the physical RAM. On a 2 GB VM that’s about 984 MB, as shown above. The remaining half of RAM stays available for applications even if \/tmp<\/code> fills up.<\/p>\n\n\n\n
When to use a real disk partition instead<\/h2>\n\n\n\n
tmpfs is the right default for almost every server. Pick a real partition instead when:<\/p>\n\n\n\n