Scenario: the user comes saying that he cannot get his X11 windows exported anymore on the destination cluster login node after the crash of one linux client he was using. Crash meaning, of course, an accidental switching off of the client performing the ssh to the login node. So I sit and test with my user account from a couple of clients to the same destination login node, successfully getting my xclock popping up after the ssh. Inspired by this post from Kittycool timeout in locking authority file, as sudo on the destination cluster I remove the .Xauthority from the user’s home and ask him to try ssh again, still not managing to get the graphics exported.
As you may know, the xauth controls the authorisation to get the graphics. It can be refreshed, it can be recreated, but also it can be also tampered by manually adding the magic cookie to it, as described also here and in my previous post. But I can’t seem to be able to add the cookie to the user’s xauth. The permissions, after comparing them with mine, also look fine. I even move the .Xauth to another location and copy mine (that works) with of course the right user’s rights, and move his whole home folder to user_bkup just to create a new clean home folder that we could use. All of that unsuccessful.
Then I try mkdir and I get a message. The answer to the riddle was always on this post. There was no free inode quota for the user. How come? Well, on my behalf, just to say that I didn’t know the user was experimenting with chopping his data onto 2 million small files for a reason that I can’t understand, and I’m in principle not responsible of the cluster, only yet another super user. Errare humanum est, or something like that.
Have a nice, cluster free, weekend 🙂