Description of Problem:
This happens to a diskless workstation that mounts its root filesystem
over NFS. When X runs on this diskless PC, the Unix domain socket for X
is created at /tmp/.X11-unix/X0 with permissions srwxr-xr-x with owner
and group root. This makes it impossible for a nonroot user to start X on
a console. The attempt would fail after some time with:
xinit: Permission denied (errno 13): unable to connect to X server
waiting for X server to shut down.
xinit: Server error.
Normally on non-NFS-mounted PCs, /tmp/.X11-unix/X0 is created with
permission srwxrwxrwx. If I change the socket to this less restrictive
permission after it is created, the X startup would proceed successfully.
Because the diskless PC is using an old SIS 6326 video chipset, I am
using a 3.3.6 X server XFree86_SVGA rather than one of the 4.x ones.
This is a specialized configuration of XFree86 that Red Hat does
not support. It is most likely a general XFree86 problem, and not
one specific to Red Hat Linux. I recommend reporting it upstream
to XFree86 directly. You may be able to receive some guidance on
the XFree86 firstname.lastname@example.org users mailing list.
Hope this helps.
The problem appears to be with 7.1's kernel. The XFree86 xpert list that you
suggested I subscribe had this reply from Dr. Martin Kroeker (email@example.com):
"If this happens with anything that gets created in the nfs-mounted
filesystem, it is a kernel (nfsd) bug present in older 2.4.x kernels
(x being something like <7). Check the kernel mailing list archive for
correct details, but in essence the initial umask was changed to 022 so
that nobody can play tricks with init, and nobody noticed that the
kernel-based nfsd inherits the same umask. Upgrading the kernel should fix
Ok, this is good to know in case someone else reports the problem,
or queries for it in bugzilla. Do you know what kernel it was
Arjan, can you comment on this umask issue with knfsd?
I'll close it as resolved in foo, when we find out what value of foo
to use. Thanks.
Does this still happen with the 2.4.9-12 errata kernel?
I have tested on the errata kernel-2.4.9-13 under Red Hat 7.2, and can verify that
this problem is not present on that version.