Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I'm logged in remotely over SSH with X forwarding to a machine running Ubuntu 10.04 (lucid). Most X11 applications (e.g. xterm, gnome-terminal) work fine. But Evince does not start. It seems unable to read ~/.Xauthority, even though the file exists, and is evidently readable (it has the right permissions and other applications read it just fine).

$ evince
X11 connection rejected because of wrong authentication.
Cannot parse arguments: Cannot open display:
DISPLAY=localhost:10.0 XAUTHORITY=
$ strace evince
access("/home/gilles/.Xauthority", R_OK) = 0
open("/home/gilles/.Xauthority", O_RDONLY) = -1 EACCES (Permission denied)
$ ls -l ~/.Xauthority
-rw------- 1 gilles gilles 496 Jul  5 13:34 /home/gilles/.Xauthority

What's so special about Evince that it can't read ~/.Xauthority? How can I make it start?

share|improve this question

1 Answer 1

up vote 6 down vote accepted

TL,DR: it's Apparmor's fault, and due to my home directory being outside /home.

Under a default installation of Ubuntu 10.04, the apparmor package is pulled in as an indirect Recommends-level dependency of the ubuntu-standard package. The system logs (/var/log/syslog) show that Apparmor is rejecting Evince's attempt to read ~/.Xauthority:

Jul 5 17:58:31 darkstar kernel: [15994724.481599] type=1503 audit(13415 03911.542:168): operation="open" pid=9806 parent=9805 profile="/usr/bin/evince" requested_mask="r::" denied_mask="r::" fsuid=1001 ouid=1001 name="/elsewhere/home/gilles/.Xauthority"

The default Evince configuration for Apparmor (in /etc/apparmor.d/usr.bin.evince) is very permissive: it allows arbitrary reads and writes under all home directories. However, my home directory on this machine is a symbolic link to non-standard location which is not listed in the default AppArmor configuration. Access is allowed under /home, but the real location of my home directory is /elsewhere/home/gilles, so access is denied.

Other applications that might be affected by this issue include:

  • Firefox, but its profile is disabled by default (by the presence of a symbolic link /etc/apparmor.d/disable/usr.bin.firefox -> /etc/apparmor.d/usr.bin.firefox).
  • CUPS PDF printing; I haven't tested, but I expect it to fail writing to ~/PDF.

My fix was to edit /etc/apparmor.d/tunables/home.d/local and add the line


to have the non-standard location of home directories recognized (note that the final / is important; see the comments in /etc/apparmor.d/tunables/home.d/ubuntu), then run /etc/init.d/apparmor reload to update the Apparmor settings.

If you don't have administrator privileges and the system administrator is unresponsive, you can copy the evince binary to a different location such as ~/bin, and it won't be covered by the Apparmor policy (so you'll be able to start it, but will not be afforded the very limited extra security that Apparmor provides).

This issue has been reported as Ubuntu bug #447292. The resolution handles the case when some users have their home directory as listen in /etc/passwd outside /home, but not cases such as mine where /home/gilles is a symbolic link.

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.