Hide Forgot
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: giving up. 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 xpert@xfree86.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 (mk@daveg.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 this."
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 fixed in? 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.