Fedora – Should I be concerned with the error xauth: /home/user/.serverauth.535 does not exist

My guess is that, when you run startx, you don't have an active ConsoleKit session. See e.g. Set up PolicyKit permissions in the Arch Linux wiki entry for NetworkManager. It shows you how to use ck-launch-session in your ~/.xinitrc to make sure you have a proper CK session.

You also need to make sure that PolicyKit permissions are right, although they're probably already fine if things work from inside a Gnome session.

If the command ck-list-sessions shows a difference between using runlevel5.target versus runlevel3.target+startx, then this is probably your issue.

See also:

Administration and Privilege at the bottom of the Network Manager Configuration page.

I don't recommend that you follow what these say without understanding what they're doing, since it's not necessarily clear how they relate to Fedora, but they might be useful reading:

This Ubuntu bug: If 'startx' is run from within a text console, ConsoleKit session is not marked 'active'

This Debian mailing list post that has some details about changing policykit/consolekit permissions: Re: What is the right way to use consolekit with startx?

Running an strace on the remote system where xauth is failing will show you what's tripping up xauth.

For example

$ strace xauth list
stat("/home/sam/.Xauthority-c", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
open("/home/sam/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0}, 0x7fff6c4430e0)       = 0
open("/home/sam/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0}, 0x7fff6c4430e0)       = 0
open("/home/sam/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0

So xauth is attempting to open a file and it already exists. The culprit file is /home/sam/.Xauthority-c. We can confirm the presence of this file on the remote system:

$ ls -l .Xauthority*
-rw------- 1 sam sam 55 Jul 12 22:04 .Xauthority
-rw------- 1 sam sam  0 Jul 12 22:36 .Xauthority-c
-rw------- 1 sam sam  0 Jul 12 22:36 .Xauthority-l

The fix

As it turns out. Those files are lock files for .Xauthority, so simply removing them resolves the issue.

$ rm -fr .Xauthority-*

With the files deleted, exit from the SSH connection and then reconnect. This will allow xauth to re-run successfully.

$ ssh -t skinner ssh sam@blackbird
Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-44-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

Last login: Sun Jul 12 22:37:54 2015 from skinner.bubba.net
$

Now we're able to run xauth list and X11 applications without issue.

$ xauth list
blackbird/unix:10  MIT-MAGIC-COOKIE-1  cf01f793d2a5ece0ea58196ab5a7977a

The GUI

$ xeyes

Alternative method to resolve the issue

I came across this post titled: xauth: error in locking authority file .Xauthority [linux, ssh, X11] which mentions the use of xauth -b to break any lock files that may be hanging around. xauth's man page seems to back this up:

 -b      This option indicates that xauth should attempt to break any
         authority file locks before proceeding.  Use this option only to
         clean up stale locks.

References

• Dealing with xauth “error in locking authority file” errors