Yeah, that permission denied on /tmp is a classic. Don't sweat it — I've seen this a hundred times. The fix is usually quick, but you gotta look in the right places.
The Immediate Fix
First, check the permissions on /tmp. You want to see drwxrwxrwt. That t is the sticky bit — it means only the owner of a file (or root) can delete it, even if the directory is world-writable.
ls -ld /tmpIf you see something like drwxr-xr-x or drwxrwxr-x, the sticky bit is missing. Fix it with:
sudo chmod 1777 /tmpThat sets the sticky bit (the 1) plus full read/write/execute for everyone. This is the standard mode for /tmp on any Linux system. You'll see it on every distro from Ubuntu to RHEL.
Now try your command again. If it works, done. But if you're still getting permission denied, especially on CentOS or RHEL, the culprit is almost always SELinux.
When SELinux Is the Problem
SELinux labels files with a security context. If something got mislabeled — maybe you mounted a drive, copied files, or ran a container — the label on /tmp might be wrong, and SELinux will deny access even with perfect Unix permissions.
Check the context:
ls -Zd /tmpYou should see something like system_u:object_r:tmp_t:s0. If it's different, relabel it:
sudo restorecon -v /tmpThat restores the default SELinux context. If that doesn't do it, check the SELinux type enforcement on the process that's being denied. Look at the audit log:
sudo ausearch -m avc -ts recentYou'll see entries like avc: denied { write } for pid=1234 comm="myapp" name="tmp" dev="sda1". That tells you exactly which process and what action got denied.
You can either set the right context for that process or, if you're in a hurry and it's a dev box, toggle SELinux to permissive:
sudo setenforce 0But don't leave it like that in production. That's asking for trouble.
Why This Works
The sticky bit is there to prevent one user from deleting another user's temporary files. Without it, any user could wipe out /tmp and break other people's apps. The standard 1777 mode is the default on every sane Linux system. When it gets changed — maybe by a misconfigured install script or an overzealous admin — you get permission errors for everyone trying to create files there.
SELinux is a different beast. It's a mandatory access control system that sits on top of Unix permissions. Even if /tmp is world-writable, SELinux can block a process from using it if the process's type doesn't have the right rules. When you restore the context, you're telling SELinux "this is the normal tmp_t type, apply the standard rules."
One more thing: if you're using systemd with a private /tmp for a service (PrivateTmp=true), that creates a separate namespace with its own /tmp that's walled off from the real one. If your app is running as a service and can't see files you place in /tmp, that's why. Check the service unit:
systemctl cat your-serviceLook for PrivateTmp=true in the file. If it's there, you'll need to put files in the service's private tmp, or disable that option if it's not required.
Less Common Variations
Here's a few weird ones I've hit over the years.
1. Mounted over /tmp
Someone mounted a new filesystem on /tmp without the right options. Check with mount | grep /tmp. If it's a tmpfs, it should have mode=1777 in the options. If not, remount it:
sudo mount -o remount,mode=1777 /tmp2. User namespace sandboxing
On Ubuntu, AppArmor can also block access to /tmp for specific profiles. Check dmesg | grep apparmor for denials. The fix is to adjust the profile or add an allow rule.
3. Filesystem mounted noexec or nodev
If /tmp is mounted with noexec, you can create files but not execute them. That's a security measure, but it can break install scripts. Check your /etc/fstab for noexec. If you need exec, remove it and remount.
Prevention
Don't mess with /tmp permissions. Standard is 1777, period. If you're automating server setup, make sure your provisioning scripts set that explicitly. And keep SELinux in enforcing mode — it's your friend, just make sure you understand the labels.
For services that need their own tmp space, use PrivateTmp=true deliberately. That's a feature, not a bug. It isolates each service's temp files from the rest of the system.
Finally, if you're going to relabel files or change contexts, use restorecon rather than manually setting contexts. It's less error-prone.
That's it. You'll be back up in minutes.