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.

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

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

Had the same problem, and your answer pointed me in the right direction. I found a different solution which does not require editing the apparmor configuration. Instead of using a symlink to redirect access to /home, use the bind option on mount. I added the following line to /etc/fstab:

/elsewhere/home /home none bind

Once you do this, apparmor won't even know that directories under /home are "really" located somewhere else, so the complaints will go away.

The advantage of this approach is that it will work for all applications, without having to edit a different apparmor configuration file for each one.

share|improve this answer
That wouldn't have been applicable in my case: there were home directories under /home and others not under /home. A variant for this case is to bind-mount /elsewhere/home/gilles to /home/gilles, or /elsewhere/home to /home/elsewhere. – Gilles May 20 '15 at 15:33
up vote 7 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.