Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

There is daemon in my system, it runs inside of a screen instance and all that is done from an unpriveleged user. I’ve added myself to special sudo group allowing me to run screen from this user, but when I try to use it, e.g.

sudo -u that_user -H /usr/bin/screen -R

I get the subject of this post.

Digging around I found that this message means that screen cannot grab or do output to the pty I actually use when calling it. Common answer to this is to chmod my /dev/pts/N to be rw for the others, but I remember I somehow managed to avoid this earlier. Maybe I missed to save some environment for sudo?

In particular I’m trying to connect to rtorrent daemon running in screen from an ordinary user via sudo, OS is Gentoo amd64. Here is how screen is called from the rc-script:

    start-stop-daemon \
        --start \
        --make-pidfile \
        --pidfile /var/run/ \
        --background \
        --user $USER \
        --env HOME="${PWHOME:-/home/$USER}" \
        --name rtorrent \
        --exec /usr/bin/screen -- -D -m -S rtorrentd /usr/bin/rtorrent

Finally worked the actual solution out:

alias rtorrent="urxvt -hold -e /bin/bash -c \"chmod o+rw \\\`tty\\\` && sudo -u rtorrent -H screen -r rtorrentd\""
share|improve this question
up vote 5 down vote accepted

Since you are running screen as the special user, the special user needs access to your pty. The only way to accomplish this is to change the permissions on the device.

A better approach is to use screen's multiuser feature, which allow users to connect to another user's screen session without using sudo. This requires setting the screen binary setuid root:

sudo chmod u+s /usr/bin/screen

Then create a new screen session, giving the socket a meaningful name:

screen -S torrent

Inside this screen session, enable multiuser mode and authorise the other users:

^A: multiuser on
^A: acladd tijagi

You should then be able to attach the screen session as yourself:

screen -x that_user/torrent
share|improve this answer
Thanks for the reply, but it doesn’t work for me for some reason. Here is the output: But I’m afraid of using screen with root setuid anyway, so I’m thinking about to run screen for rtorrent in a special urxvt window which will change its permissions on the fly. – tijagi Feb 4 '13 at 20:12
@tijagi Did you start a new named screen session with screen -S rtorrentd? – mgorven Feb 4 '13 at 20:47
Look at the my first post, I’ve expanded it. – tijagi Feb 4 '13 at 21:07
@tijagi That all looks fine, I'm not sure why it's not working. – mgorven Feb 5 '13 at 0:39
Is it possible to enable this via .screenrc? – earthmeLon Apr 12 '13 at 18:23

The ownership of the terminal device is not changed when using sudo, but changing its permissions is actually not the only solution (not a great solution though, because it opens a security hole).

The common approach is to start a "script" session (but don't save the output, send it to the trash), which works because it uses another terminal device.

sudo -su USER script -c bash /dev/null
# new terminal with sufficient permissions for screen
screen -R

Or all in one command, e.g., as alias in your .bashrc:

alias user-screen-attach='sudo -su USER script -c "screen -x" /dev/null'
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.