Home / server / Questions / 127383
In Process
Kamil Kisiel
Asked: 2010-03-30 09:30:10 +0800 CST

Sporadic '.Xauthority not writable, changes will be ignored' going from OSX -> Linux

  • 772

Every now and then when users SSH from their OS X (Snow Leopard) workstation to one of our Linux hosts they receive the message:

/usr/bin/xauth: ~/.Xauthority not writable, changes will be ignored

Of course, their X forwarded applications will not work at this point.

However, if they log out and log right back in again they do not get the message and everything works as expected.

On their Mac they get their home directory via AFP. The Linux machines get it via NFS.

Any ideas on what could be going on here?

linux mac-osx x11

3 Answers

  1. I can't help but wonder if you are seeing a race condition, perhaps something like this:

    • User logs into an OS X client, which mounts the home folder over AFP
    • User sshes into a Linux host, which mounts the home that the OS X client has mounted, but does so over AFP.
    • Linux host reads (writes?) to ~/.Xauthority and the file is locked -- either intentionally (as part of the checking process) or not (something the server does to prevent the same file from being written to by two systems using different protocols, or heck, to prevent two different systems from stomping on one file at the same time, regardless of protocol).
    • Original Mac OS X client wants to record data about the session [aside: I really don't know what .Xauthority is used for] and tries to access the file
    • It is told the file is locked
    • About this time, the Linux box is done with the file, and it becomes unlocked

    On a different attempt, it may be that:

    1) they are attempting to connect to a known host and the OS X client doesn't need to record any information and doesn't access .Xauthority, or 2) the timing is out enough that the two systems don't try to use the same file at the same time [hence this being a race condition].

    I'm not certain how you could tell if this is the case. I think you could use the fs_usage command on the server (or a GUI tool like fseventer) to see if the same file is being access in rapid succession, although that doesn't necessarily prove anything.

    You might be able to glean useful information by using lsof, on either the files or (lsof -i) network connections. Possibly you could turn on logging for AFP and NFS (or use nfsstat?) and cross reference them.

    I'd consider compiling iftop, but, all you should see when running it is that, yes, there are connections to the server from both the Mac client and the Linux client, and they are using different ports and transferring information.

    I'd recommend having a test user ssh in using different accounts on the Mac client and Linux host for a while and see if the issue comes up for them. If it doesn't, then it does have something to do with using the same account in two places at once (and quite likely due to mounting the home folder twice).

    It may be worth seeing if you can configure OS X and Linux to use different copies of the Xauthority file. (I'm not sure if you can even do that).

    I would also try having a test user access their home folder on OS X over NFS and see if that makes a difference.

    • 1

  2. Had that once ages ago starting a few dozen X apps via ssh. ssh uses xauth which itself locks the .Xauthority file and will plain fail if it cannot lock it. Solved that back then by modifying the xauth program to spin on the lock instead, but do not have the patch anymore.

    • 0

  3. If the ssh_config file does not have ForwardX11 set you may have to use -X on the ssh command. I.E. see if

    ssh -X machineName

    works

    • -3