Running into the “cannot make directory /run/screen: permission denied” error can be frustrating. This error indicates that your Linux system is preventing you from creating the /run/screen directory due to permissions issues.
Fortunately, there are a few potential solutions for troubleshooting and fixing this problem. When this error message pops up, it means your user account lacks the proper permissions to create directories in the /run/screen location.
The /run directory is a tmpfs (temporary file storage) location that gets cleared out during reboot. The screen utility wants to store runtime data here temporarily, but cannot due to the permissions restriction.
What Causes This Permission Error?
There are a few common culprits for the “cannot make directory /run/screen” permissions problem:
Incorrect Ownership or File Permissions on /run
On some Linux distributions, the /run directory is owned by the root user. Regular user accounts therefore do not have write access. Trying to launch the screen before changing permissions would result in the error.
SELinux or AppArmor Security Policies
Security Enhanced Linux (SELinux) and AppArmor provide access controls that confine applications. If policies are too restrictive, these mechanisms may block the screen from accessing /run.
Filesystem Mounted as Read-Only
If the tmpfs filesystem holding /run is somehow mounted read-only, attempts to write files here would fail.
Fortunately, the solutions will depend on exactly what is causing the permissions issue on your system.
Troubleshooting and Fixing
Check Ownership and Permissions of /run
The first troubleshooting step is to inspect the ownership and permissions of /run using:
ls -ld /run
On many distros, this directory is owned by root:root. The output may show:
drwxr-xr-x root root /run
The important bits are the first “rwx” portion, indicating root has read/write/execute access. The second “rx” portion means that only read and execute access is granted to all other users.
This explains why attempts to create a subdirectory here would be denied – your user lacks write permissions.
Temporarily Grant Your User Access
If /run permissions are indeed too restrictive, you can temporarily grant your user account write access with:
sudo chmod 777 /run
Then retry launching screen. If it now works properly, you can optionally set permissions back after starting your screen session:
sudo chmod 755 /run
While workable, leaving world writeable permissions on /run long term is risky from a security perspective. But this proves permissions were at fault. We can explore better options next.
Adjust SELinux/AppArmor Security Contexts
If your system utilizes SELinux, AppArmor or other MAC (Mandatory Access Control) mechanisms, they may block the screen from accessing /run.
First, check if SELinux is enforcing with getenforce. If so, ensure the screen processes domain has proper rights to tmpfs filesystems:
sudo semanage fcontext -a -t screen_t ‘/run/screen’
For AppArmor, load screen profiles to explicitly allow /run usage if needed:
sudo aa-complain screen /usr/bin/screen
Then try screen again. If these contexts fixes allow it to work properly by granting the needed /run permissions, you can leave them in place as a solution.
Remount Filesystem as Read-Write
In very rare cases, the /run tmpfs filesystem itself could have the read-only flag set, preventing writes. Use mount to inspect the flags on /run. If ro appears, remount it read-write:
sudo mount -o remount,rw /run
This allows writes to /run again so screen can create its /run/screen socket and files. The remount option persists across reboots as well.
Create /run/screen on Reboot
If adjusting ownership or permissions system-wide on /run itself seems overly intrusive, an alternative that is both secure and persistent across reboots is this systemd service unit:
/etc/systemd/system/createscreenrundir.service
[Unit]
Description=Create /run/screen directory
Before=screen-server.service
[Service]
Type=oneshot
ExecStart=/bin/mkdir -p /run/screen
ExecStart=/bin/chmod 755 /run/screen
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
This simple unit makes sure the /run/screen subdirectory exists with proper permissions before the screen service starts.
After creating this unit, enable it so it runs on each reboot:
sudo systemctl enable createscreenrundir
No need to explicitly launch it – systemd activates it automatically when the screen starts up. This avoids the permission error by ensuring the screen’s runtime directory under /run exists ahead of time.
Conclusion
The “cannot make directory /run/screen: permission denied” error arises when the screen lacks write access to create its necessary /run/screen path. Adjusting ownership, permissions, SELinux contexts, or read-only mount flags can all provide permissions for a quick fix.
Or create the proper /run subdirectory on boot via a custom systemd unit. With the right Linux permissions troubleshooting, the screen can once again connect successfully.
