2

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?

Kamil Kisiel
  • 12,184
  • 7
  • 48
  • 69
  • Can you have them check the permissions on the ~/.Xauthority file, before they try to ssh in, and see if there is a pattern for when it works and when it doesn't? Also, does a Mac user get, over AFP, the *same* home folder that he gets on a Linux box over NFS? I am wondering if you have the same home folder mounted in two places at once. – Clinton Blackmore Mar 29 '10 at 18:19
  • Yes it's the same home folder in both cases (as it should be). – Kamil Kisiel Mar 29 '10 at 19:02
  • What kind of server have you got on the back end? I know some complained about a file being mounted in two places, especially if it was done by different protocols. (As I understand it, using Mac OS X Tiger server or earlier, and mounting a folder over AFP and SMB caused problems). – Clinton Blackmore Mar 29 '10 at 19:24
  • It's an X-Serve with OS X Server 10.6 – Kamil Kisiel Mar 29 '10 at 20:17
  • Is the NFS mount done over TCP, with the `hard` option? – 200_success Aug 19 '13 at 20:55

3 Answers3

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.

Clinton Blackmore
  • 3,520
  • 6
  • 36
  • 61
0

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.

rackandboneman
  • 2,577
  • 11
  • 8
-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

Coolwater357
  • 1