I have installed screen on Fedora 19. When I test the command as root remotely through SSH, it works perfectly. For instance, if I enter screen a new terminal emulator is started and waits for commands. I can detach it, etc. However when I try to do the same once I am logged remotely through SSH as a standard user, the command terminates immediately. The only message I see is [screen is terminating].

Does someone have already had this problem? Is it related to bad permissions?


$ strace -e trace=file screen
execve("/usr/bin/screen", ["screen"], [/* 23 vars */]) = 0
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libutempter.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libpam.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libfreebl3.so", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libaudit.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
access("/home/steam/.nethackrc", F_OK)  = -1 ENOENT (No such file or directory)
readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
stat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
lstat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
open("/var/run/utmp", O_RDONLY)         = 3
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
open("/etc/shadow", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
stat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
stat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
lstat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
stat("/var/run/screen", {st_mode=S_IFDIR|0775, st_size=60, ...}) = 0
Directory '/var/run/screen' must have mode 777.
+++ exited with 1 +++

I have tried to change permissions to 777 but then when I execute screen, I get:

Directory '/var/run/screen' must have mode 775.

Therefore, I have reverted my changes.

  • What is the command?
    – ewwhite
    Commented Oct 6, 2013 at 11:49
  • The simplest one: "screen". I recorded an example at shelr.tv/records/525179c7966080791000005f
    – Laurent
    Commented Oct 6, 2013 at 15:04
  • Are you on a VPS or hosted server, by chance?
    – ewwhite
    Commented Oct 6, 2013 at 15:20
  • It is an hosted server
    – Laurent
    Commented Oct 6, 2013 at 15:21
  • strace -e trace=file screen to check if it fails on file access. Or uses tmuxas a work-around, its works the same except it uses ^b instead of ^a.
    – Emmanuel
    Commented Oct 7, 2013 at 16:30

10 Answers 10


The flip-flopping between "must have mode 777" and "must have mode 775" is caused by strace.

screen is usually a setuid or setgid program. It gains extra privileges when it is executed, which is uses to create socket files and/or modify utmp.

When a process is being traced, setuid and setgid are disabled. The tracing process, controlled by the less-privileged user, can take over the traced process so it must run without its extra privileges to avoid giving the original user too much power.

screen detects whether it is being run with setuid privileges, setgid privileges, or neither, and adjusts its expectation of the directory permissions accordingly.

So this creates a class of problems that can't be easily debugged with strace.

But if you're root, there is a workaround! If the tracing process is running as root, then the traced process can gain privileges normally. So here's what you do:

  1. Open 2 new terminals
  2. In the first terminal, log in to the remote machine as root
  3. In the second terminal, log in to the remote machine as normal user
  4. Use ps to get the PID of the normal user's shell process in the second terminal
  5. In the first terminal, run strace -f -p SHELLPID
  6. In the second terminal, run screen and watch it fail
  7. In the first terminal, you now have the strace log you need to find out what's really wrong.

The key addition to the strace command is the -f option, which tells it to trace child processes. You need it to trace the screen that will be a child of the shell process you specified with -p.

I also like to use -ff and specify an output file with -o, as in

strace -ff -o /tmp/screentrace -p SHELLPID

which will create a separate output file for each child process. Afterward you read them with less /tmp/screentrace* and the result is usually cleaner than what you get using a single -f.


Now that I've seen the strace output, I don't know exactly what went wrong, but this line is the most surprising thing in the trace:

chown("/dev/pts/2", 1002, 5)            = -1 EPERM (Operation not permitted)

A few lines earlier, it created a pty, which was revealed by TIOCGPTN to be number 2.

open("/dev/ptmx", O_RDWR)               = 5
ioctl(5, TIOCGPTN, [2])                 = 0
stat("/dev/pts/2", {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0

But it was unable to chown it. I don't know why that chown would fail, but the chown failure does give a plausible reason why screen gave up. You can get a little more information by adding -v to the strace options, and looking at the stat after the TIOCGPTN to see who owns the /dev/pts/ entry.

  • Thank you for the detailed procedure. I have tried to look at the output generated by strace but I cannot figure out what is wrong. Hereafter is the link with the content of the three files generated by strace: pastebin.com/raw.php?i=aeqDwTBX any idea is welcomed :)
    – Laurent
    Commented Oct 14, 2013 at 20:36

Ensure no other screen is using that device

This can be achieved with https://superuser.com/questions/97844/how-can-i-determine-what-process-has-a-file-open-in-linux :

sudo lsof /dev/ttyS0

And then kill that process if that is the case.

For some reason, under this condition, sudo screen can still access the device, but then that connection will miss characters, which are consumed by the other screen.

A common case where this happens is if you detached from screen with Ctrl + A D, leaving it running on the background, rather than killing it with Ctrl + A K.

Ensure the user has read and write permission to the file

E.g. on Ubuntu you want to add the user to the dialout group: https://askubuntu.com/a/133244/52975

sudo usermod -a -G dialout $USER
  • As an alternative, sudo adduser $USER dialout does the same as your usermod command Commented Aug 21, 2022 at 9:50

When I encountered this error message. I had to adjust my permissions with the following:

chmod 2775 /usr/bin/screen

And this resolved the issue for me. The 2 is very important for the correct access permissions.

You should read up more on SUID, SGID, Sticky Bit, ACL's and how they impact access.

  • u+s works. It's not nice but I can't see other solutions at the moment. Commented Jul 24, 2015 at 19:14

On of possible reasons for that bug - incorrect selinux policies, but according to redhat bugtracker such errors were fixed in fedora 17/18.

As workaround you can change variable SCREENDIR in you ~/.bashrc to something like $HOME/.screen.

  • 1
    I have tried but it does not solve the issue.
    – Laurent
    Commented Oct 14, 2013 at 20:21

Screen command was already running. So I terminated it and retyped the command. Yes this is not a pretty good resolution like others but it takes less time to do this.

Just ps and find the pid, kill PID and go ahead with retyping screen command again.

If you are running multiple screen commands, make sure you terminate the correct process associated with your terminal.


I found this issue resolved after commenting the following line in /etc/fstab and rebooting:

devpts         /dev/pts        devpts  defaults        0       0

I got exactly the same issue and a pretty similar strace output.

This fixed it:

sudo chmod u+s /usr/bin/screen
sudo chmod 755 /var/run/screen

credits: https://www.linuxquestions.org/questions/linux-newbie-8/screen-terminates-immediately-4175444530/


In my case, just logout from current session and relogin, and the screen works again.


This is a different issue, but I figured it could be useful to someone landing here just because of the title:

I noticed that when I exit screen with Ctrl + a d (detach), the process is not terminated and if I try to start another session I get the [screen is terminating] error. Starting with sudo works. Killing the process also works.

If I exit with Ctrl + a \ (quit), I can start another session normally without sudo.


I had this issue because I was running from an unprivileged user whose default shell was /bin/false. The fix was simply to put: shell "/bin/bash" in ~/.screenrc.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .