When I switched from su+bash to su+tmux+zsh I noticed that I get the $XAUTHORITY variable defined as /root/.xauthXXXXXX where XXXXXX are 6 random alphanumeric characters. With the previous configuration, X worked with root flawlessly, but now I need to copy ~username/.Xauthority to $XAUTHORITY.

The variable is defined nowhere; I checked .zshrc, /etc/profile*, /etc/profile.d/* etc.

# env

% su 
ls: cannot access /root/.xauthUSzLl4: No such file or directory
# cat .tmux.conf 
set -g default-command /bin/zsh
set -g default-shell /bin/zsh

su is aliased to su - toor and it opens tmux as shell. toor is an alias of root with different shell.

I just discovered that it appears on normal su as well. It did not do that some time ago.

set-environment did not work.

xhost +localhost did not work, but xhost + (disabling all control) DID work.

  • Could you be more specific about when you are executing what?
    – gvkv
    Sep 20, 2010 at 20:42
  • It's too bad my theory didn't pan out but if you fix it, please post your solution.
    – gvkv
    Sep 22, 2010 at 2:50
  • @Gilles: No. I didn't. Jan 18, 2011 at 19:55

3 Answers 3


Here's what I think is happening.

When you're using su and bash, the su-session inherits the environment with the exception of USER, HOME and SHELL, thus XAUTHORITY still points to ~username/.Xauthority and everything is fine. However (from the man page), when the tmux server is started:

... tmux copies the environment into the global environment; in addition, each session has a session environment. When a window is created, the session and global environments are merged with the session environment overriding any variable present in both.

and I suspect (without knowing invocation details) that when you switch credentials, su tries to find .Xauthority in /root and since it can't find one when you need to run an X app, it creates one. I can think of a couple ways you can try to fix this:

  1. Invoke su by using su -. This will copy over the real user's evironment
  2. Add set-environment <name> <value> to your tmux config.

Unfortunately, I can't test this since I recently switched over to i3 (which is awesome) and I don't have a spare machine.

  • Except that I'm invoking su by su -. Also echo "$XAUTHORITY" shows there is no ~. I'll try set-enviroment. Sep 20, 2010 at 21:47
  • Actually I meant ~ as a shorthand to (what I presumed) was your home directory. I've edited.
    – gvkv
    Sep 20, 2010 at 23:26
  • 1
    no, i3 is i3, awesome is awesome =P . Feb 15, 2011 at 9:40

This could be due to a misconfigured pam_xauth PAM module. It is supposed to copy your keys to a temporary file when you run su. The behavior you describe is consistent with pam_xauth creating the temporary file but somehow not copying the keys (perhaps because you have a ~/.xauth/export or a /root/.xauth/import).

  • I don't have neither of those but xauth is loaded in su session (i.e. it is in /etc/pam.d/su). Nov 18, 2010 at 0:19

It happened to me but this time with $COLORTERM variable.

If you start tmux on a terminal emulator that has, for instance, COLORTERM=terminus and after that you start another tmux session even on another terminal client that normally would have COLORTERM=gnome-terminal, this new session will crossover and inherit COLORTERM=terminus.

These assertions are enough to conclude that, unfortunately, tmux sessions are not isolated from each other, even if you're using different terminal emulators.

Your su sub shell is probably inheriting $XAUTHORITY from another tmux session, more specifically the very first tmux session created.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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