FAQ
I am at my wits end, googling, trying various things, and nothing seems
to really solve my problem, so I thought I would break down and write to
the community to see if anyone else has run into the issue and actually
solved it. My environment of interest contains a mix of various Fedora
and CentOS workstations that all participate in NIS for user
authentication which then, upon a successful login, automount an NFS
$HOME directory. And here is the rub, I am migrating that NFS back end
FROM a Sun X4540 (which has been working flawlessly for the past few
years) to an HP X9320 Ibrix system. I replicated my NFS exports from
one system to the other, and have tested command line logins over SSH
using NIS credentials and that all seems to work quite well. However,
whenever a CentOS (or even Fedora for that matter) desktop user tries to
log in (either Gnome or KDE) they are unable to successfully log in -
and are presented with the nebulous .dmrc error as follows:



User's $HOME/.dmrc file is being ignored. This prevents the default
session and language from being saved. File should be owned by user and
have 644 permissions. User's $HOME directory must be owned by user and
not writeable by any other users.



Followed promptly by



Your session only lasted less than 10 seconds. If you have not logged
out yourself this could mean that there is some installation problem or
that you may be out of disk space. Try logging in with one of the
failsafe sessions to see if you can fix this problem.



Now I have, of course, checked the permissions and ownership of the
$HOME directory and also the .dmrc file and they are correct - but no
matter what I do, this fails.



Things I have tried: with NIS turned on, without NIS turned on, using
automount, without using automount, using all different kinds of NFS
options passed to a local mount of the /ibrix/testing area which I am
using to test GUI logins from the local workstation under Gnome or KDE -
all to no avail. And of course I have spent countless hours/days
googling and have even written to HP for some advice.



I am pretty confident that perms/ownerships are correct, but I just cant
seem to get anything to work. Has anyone run into a similar problem? Has
anyone found a solution? Does anyone have any suggestions that I am not
thinking about?



I appreciate your time and assistance

Michael Weiner


===================================

Please consider the environment before printing this e-mail

Cleveland Clinic is ranked one of the top hospitals
in America by U.S.News & World Report (2010).
Visit us online at http://www.clevelandclinic.org for
a complete listing of our services, staff and
locations.


Confidentiality Note: This message is intended for use
only by the individual or entity to which it is addressed
and may contain information that is privileged,
confidential, and exempt from disclosure under applicable
law. If the reader of this message is not the intended
recipient or the employee or agent responsible for
delivering the message to the intended recipient, you are
hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If
you have received this communication in error, please
contact the sender immediately and destroy the material in
its entirety, whether electronic or hard copy. Thank you.

Search Discussions

  • Lucian at Jan 26, 2012 at 11:36 am

    On 26 January 2012 15:46, Weiner, Michael wrote:
    I am at my wits end, googling, trying various things, and nothing seems
    to really solve my problem
    Hello,

    Check /var/log/audit/audit.log, maybe it's a Selinux related problem.
    Were you using Selinux on those Centos/Fedora installations
    previously? Maybe the contexts haven't been migrated over (properly).
  • Weiner, Michael at Jan 26, 2012 at 11:39 am
    On Behalf Of Lucian
    Check /var/log/audit/audit.log, maybe it's a Selinux related problem.
    Were you using Selinux on those Centos/Fedora installations
    previously? Maybe the contexts haven't been migrated over (properly).
    Thank you for your reply. I normally disable selinux, but its worth
    checking out :)

    Michael

    ===================================

    Please consider the environment before printing this e-mail

    Cleveland Clinic is ranked one of the top hospitals
    in America by U.S.News & World Report (2010).
    Visit us online at http://www.clevelandclinic.org for
    a complete listing of our services, staff and
    locations.


    Confidentiality Note: This message is intended for use
    only by the individual or entity to which it is addressed
    and may contain information that is privileged,
    confidential, and exempt from disclosure under applicable
    law. If the reader of this message is not the intended
    recipient or the employee or agent responsible for
    delivering the message to the intended recipient, you are
    hereby notified that any dissemination, distribution or
    copying of this communication is strictly prohibited. If
    you have received this communication in error, please
    contact the sender immediately and destroy the material in
    its entirety, whether electronic or hard copy. Thank you.
  • Tru Huynh at Jan 26, 2012 at 2:28 pm

    On Thu, Jan 26, 2012 at 11:39:35AM -0500, Weiner, Michael wrote:
    On Behalf Of Lucian
    Check /var/log/audit/audit.log, maybe it's a Selinux related problem.
    Were you using Selinux on those Centos/Fedora installations
    previously? Maybe the contexts haven't been migrated over (properly).
    Thank you for your reply. I normally disable selinux, but its worth
    checking out :)
    <snip lenghty signature>

    no issue here on CentOS-6.2 2.6.32-220.4.1.el6.x86_64
    selinux enforced (but I have setsebool -P use_nfs_home_dirs=1)

    ibrix:/ibfs1/tru mounted as /home/ibrix (newly created ibrix user)

    Tru
    --
    Tru Huynh (mirrors, CentOS i386/x86_64 Package Maintenance)
    http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBEFA581B
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos/attachments/20120126/c6a65dc4/attachment.bin
  • Michael Weiner at Jan 26, 2012 at 2:48 pm

    On Thu, Jan 26, 2012 at 2:28 PM, Tru Huynh wrote:
    no issue here on CentOS-6.2 2.6.32-220.4.1.el6.x86_64
    selinux enforced (but I have setsebool -P use_nfs_home_dirs=1)

    ibrix:/ibfs1/tru mounted as /home/ibrix (newly created ibrix user)
    Tru -

    Thank you for your response. When you created the NFS export on the
    IBRIX system, what options did you use? I am currently using its
    defaults of RW, NO_ROOT_SQUASH

    Thanks
    Michael
  • Tru Huynh at Jan 27, 2012 at 3:44 am

    On Thu, Jan 26, 2012 at 02:48:14PM -0500, Michael Weiner wrote:
    On Thu, Jan 26, 2012 at 2:28 PM, Tru Huynh wrote:
    no issue here on CentOS-6.2 2.6.32-220.4.1.el6.x86_64
    selinux enforced (but I have setsebool -P use_nfs_home_dirs=1)

    ibrix:/ibfs1/tru mounted as /home/ibrix (newly created ibrix user)
    Tru -

    Thank you for your response. When you created the NFS export on the
    IBRIX system, what options did you use? I am currently using its
    defaults of RW, NO_ROOT_SQUASH
    [root at xxxxxxx ~]# ibrix_version -l
    Fusion Manager version: 6.0.326
    ===============================
    Segment Servers
    ===============
    HOST_NAME FILE_SYSTEM IAD/IAS IAD/FS OS KERNEL_VERSION ARCH
    --------- ------------------ ------- ------- --------- -------------- ----
    xxxxxxxx1 6.0.326(X9000_6_0) 6.0.326 6.0.326 GNU/Linux 2.6.18-194.el5 x86_64
    xxxxxxxx2 6.0.326(X9000_6_0) 6.0.326 6.0.326 GNU/Linux 2.6.18-194.el5 x86_64
    - l'export et les options que tu as utilis??
    [root at hummer-s2 ~]# ibrix_exportfs -l
    HOSTNAME FSNAME PATH OPTIONS
    --------- ------ --------------------------------- -------
    xxxxxxxx1 ibfs1 centos6:/ibfs1/tru rw,no_root_squash
    xxxxxxxx1 ibfs1 centos5:/ibfs1/tru rw,no_root_squash
    xxxxxxxx2 ibfs1 centos6:/ibfs1/tru rw,no_root_squash
    xxxxxxxx2 ibfs1 centos5:/ibfs1/tru rw,no_root_squash

    In the CentOS-5 and CentOS-6 machines, mount reports:
    ibrix:/ibfs1/tru on /home/ibrix type nfs (rw,addr=xxxx)

    I would check if your problematic user is created both locally
    and in your NIS/LDAP/... setup with different uid,
    restart the gdm daemon (caching? issue), stop nscd (+ flush
    the local cached data, before restarting it).

    Tru
    --
    Tru Huynh (mirrors, CentOS i386/x86_64 Package Maintenance)
    http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBEFA581B
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos/attachments/20120127/055d5daa/attachment.bin
  • Michael Weiner at Jan 27, 2012 at 9:17 am

    On Fri, Jan 27, 2012 at 3:44 AM, Tru Huynh wrote:
    [root at xxxxxxx ~]# ibrix_version -l
    ?Fusion Manager version: 6.0.326
    ?==============================> ?Segment Servers
    ?==============> ?HOST_NAME ?FILE_SYSTEM ? ? ? ? IAD/IAS ?IAD/FS ? OS ? ? ? ? KERNEL_VERSION ?ARCH
    ?--------- ?------------------ ?------- ?------- ?--------- ?-------------- ?----
    ?xxxxxxxx1 ?6.0.326(X9000_6_0) ?6.0.326 6.0.326 ?GNU/Linux ?2.6.18-194.el5 ?x86_64
    ?xxxxxxxx2 ?6.0.326(X9000_6_0) ?6.0.326 6.0.326 ?GNU/Linux ?2.6.18-194.el5 ?x86_64
    - l'export et les options que tu as utilis??
    [root at hummer-s2 ~]# ibrix_exportfs -l
    HOSTNAME ? FSNAME ?PATH ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? OPTIONS
    --------- ?------ ?--------------------------------- ?-------
    xxxxxxxx1 ?ibfs1 ? centos6:/ibfs1/tru ?rw,no_root_squash
    xxxxxxxx1 ?ibfs1 ? centos5:/ibfs1/tru ?rw,no_root_squash
    xxxxxxxx2 ?ibfs1 ? centos6:/ibfs1/tru ?rw,no_root_squash
    xxxxxxxx2 ?ibfs1 ? centos5:/ibfs1/tru ?rw,no_root_squash

    In the CentOS-5 and CentOS-6 machines, mount reports:
    ibrix:/ibfs1/tru on /home/ibrix type nfs (rw,addr=xxxx)

    I would check if your problematic user is created both locally
    and in your NIS/LDAP/... setup with different uid,
    restart the gdm daemon (caching? issue), stop nscd (+ flush
    the local cached data, before restarting it).
    Tru -

    thank you for the information, here is mine for the same

    [root at lri-brix01 ~]# ibrix_version -l
    Fusion Manager version: 6.0.326
    ============================== Segment Servers
    ============== HOST_NAME FILE_SYSTEM IAD/IAS IAD/FS OS
    KERNEL_VERSION ARCH
    ---------- ------------------ ------- ------- ---------
    -------------- ----
    lri-brix01 6.0.326(X9000_6_0) 6.0.326 6.0.326 GNU/Linux
    2.6.18-194.el5 x86_64
    lri-brix02 6.0.326(X9000_6_0) 6.0.326 6.0.326 GNU/Linux
    2.6.18-194.el5 x86_64

    and

    [root at lri-brix01 ~]# ibrix_exportfs -l
    HOSTNAME FSNAME PATH OPTIONS
    ---------- ------ ------------------------------------- -------
    lri-brix01 ibrix *:/ibrix/testing rw,no_root_squash
    ......
    <many many exportfs shares>

    On workstation, mount shows:

    lri-brix:/ibrix/testing on /bme/home type nfs (rw,addr.66.200.11)

    I even mounted the test share manually, disabling autofs and ypbind,
    and created a 'local' user with an NFS mounted $HOME directory and it
    still failed. I dont see what i have done wrong. SSH logins work, and
    the directory is traversable by the local user but still can not log
    in via Gnome or KDE.

    Michael
  • Tru Huynh at Jan 27, 2012 at 9:28 am
    On Fri, Jan 27, 2012 at 09:17:38AM -0500, Michael Weiner wrote:
    ...
    On workstation, mount shows:

    lri-brix:/ibrix/testing on /bme/home type nfs (rw,addr.66.200.11)
    ...
    try mounting to /home/username instead of /bme/home/username
    (and fixing /etc/passwd)

    no other idea for the moment.

    Tru
    --
    Tru Huynh (mirrors, CentOS i386/x86_64 Package Maintenance)
    http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBEFA581B
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos/attachments/20120127/1280dd5b/attachment.bin
  • Michael Weiner at Jan 27, 2012 at 2:27 pm

    On Fri, Jan 27, 2012 at 9:28 AM, Tru Huynh wrote:
    try mounting to /home/username instead of /bme/home/username
    (and fixing /etc/passwd)

    no other idea for the moment.
    Tru -

    Thank you for the suggestion, i did this, and it still failed with
    that .dmrc error, even AFTER i changed the RelaxPermissions to be 2
    in the gdm default.conf file and restarted the workstation. I am just
    stumped.

    Michael
  • Michael Weiner at Jan 31, 2012 at 3:10 pm

    On Fri, Jan 27, 2012 at 9:28 AM, Tru Huynh wrote:
    no other idea for the moment.
    Tru -

    I think i *MAY* have this figured out. When you do 'ibrix_fs -i' is
    compatibility set to no? If so, are you a 64-bit client only shop? I
    am wondering if our having the 64-bit mode set is causing the
    problems.

    [root at lri-brix01 temp]# ibrix_fs -i
    FileSystem: ibrix
    =================
    Total Segments : 24
    STATE : Mounted
    Mirrored? : No
    Compatible? : No

    My test, was to build a duplicate workstation as a 64-bit CentOS and
    configure it the same as the 32-bit CentOS workstation. And low and
    behold, i was ABLE to log in to a mounted $HOME directory from the
    ibrix system using NIS authentication. And i noticed that the
    compatibility is set to no, so its a 64-bit enabled filesystem.

    Thanks again
    Michael
  • Tru Huynh at Feb 1, 2012 at 5:44 am

    On Tue, Jan 31, 2012 at 03:10:15PM -0500, Michael Weiner wrote:
    On Fri, Jan 27, 2012 at 9:28 AM, Tru Huynh wrote:
    no other idea for the moment.
    Tru -

    I think i *MAY* have this figured out. When you do 'ibrix_fs -i' is
    compatibility set to no? If so, are you a 64-bit client only shop? I
    am wondering if our having the 64-bit mode set is causing the
    problems.
    I did my tests on c5/c6 x86_64 only.
    [root at lri-brix01 temp]# ibrix_fs -i
    FileSystem: ibrix
    ================> Total Segments : 24
    STATE : Mounted
    Mirrored? : No
    Compatible? : No
    [root at xxxxxx2 ~]# ibrix_fs -i
    FileSystem: ibfs1
    ================Total Segments : 4
    STATE : Mounted
    Mirrored? : No
    Compatible? : Yes,MaxSegmentsc

    I don't have account on the ibrix machine.

    imho: this should be fixed by HP/ibrix support team.
    Good luck,

    Tru
    --
    Tru Huynh (mirrors, CentOS i386/x86_64 Package Maintenance)
    http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBEFA581B
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos/attachments/20120201/33b45724/attachment.bin
  • Thomas Burns at Jan 26, 2012 at 2:22 pm

    On Thu, Jan 26, 2012 at 5:46 AM, Weiner, Michael wrote:
    Has anyone run into a similar problem?
    Different versions of NFS and automount over time and over platforms
    requiring slightly different config tweaks - this problem is always
    kicking my butt.

    Any relevant messages in /var/log/messages of the server? Is automount
    able to mount and it is "just" a permissions problem?

    I had a vaguely similar problem recently, trying to get OSX to access
    NIS/NFS, it needs different mount options in the automounter config.

    You say you tried with automount turned off, were you able to mount
    manually but not able to access? Same error message?

    What does nsswitch.conf look like?

    Generally my trouble shooting goes like this:
    1) get NIS to work ('ypcat mymap' works)
    2) mount NFS share manually with mount command and access as root
    3) access NFS share as ordinary user
    4) get automount to mount the share

    HTH,
    Dave
  • Michael Weiner at Jan 26, 2012 at 2:46 pm

    On Thu, Jan 26, 2012 at 2:22 PM, Thomas Burns wrote:

    Any relevant messages in /var/log/messages of the server? Is automount
    able to mount and it is "just" a permissions problem?

    I had a vaguely similar problem recently, trying to get OSX to access
    NIS/NFS, it needs different mount options in the automounter config.

    You say you tried with automount turned off, were you able to mount
    manually but not able to access? Same error message?

    What does nsswitch.conf look like?

    Generally my trouble shooting goes like this:
    1) get NIS to work ('ypcat mymap' works)
    2) mount NFS share manually with mount command and access as root
    3) access NFS share as ordinary user
    4) get automount to mount the share
    Thanks for your response Dave! I have been unable to find anything
    relevant in the server syslogs. But here is what i have tried:

    1) ypcat mymap gives me back what i would expect, as does a ypcat -k
    passwd | grep myusername
    2) I can mount the share manually on the workstation (using -o
    nfsvers=3,rw,hard,intr options) and it mounts and i can traverse it as
    a root user
    3) I can mount the share manually on the workstation and i can
    traverse it as root and as a local user
    4) i can then put the map in place, restart autofs, log in via a NIS
    account and it maps correctly and i can traverse it properly in a
    shell (i.e. ssh, etc)
    5) i tried mounting manually, creating a $home directory for a new
    user, giving that user a password and i can ssh in but not Gnome or
    KDE
    6) variations of the above.

    And this *IS* working currently on a Sun X4540 system, and the
    NON-HOME directories that get mapped upon login correctly map on the
    HP X9320 via NIS authentication just not X.

    Thanks for the help and logical thinking.
    Michael
  • Thomas Burns at Jan 26, 2012 at 3:40 pm

    On Thu, Jan 26, 2012 at 9:46 AM, Michael Weiner wrote:
    5) i tried mounting manually, creating a $home directory for a new
    user, giving that user a password and i can ssh in but not Gnome or
    KDE
    If it was me, I'd try creating a new home directory for that user on a
    disk local to the machine where you're trying to log in. Presumably
    the user could then log in. Then I'd check that the user could access
    the NFS share normally just not as home. If no problem there, I'd be a
    bit tempted to stop there as a workaround, because I am lazy and most
    of my users just use one machine.

    Seems possible to me that the dmrc file error message and the instant
    logout are related but not identical. Gnome just does not like NFS
    home dirs. (My experience has been, if the same user is logged in to
    two machines, kablooey!) I used to frequently see a similar problem,
    after a crash or other odd event, where the user could log in but then
    would immediately be logged out with an error similar to your second
    message. I had a magic trick I had to go through to untangle things,
    if you are desperate enough you could try it:

    * delete all files in the user's home dir that start with .gconf
    (.gconf and .gconfd).
    * delete all files in /tmp.
    * reboot to make sure all processes release old corrupted files.
    * if feeling paranoid, before having the user try to log in, check
    again as root that /tmp is empty and nothing in user's home dir is
    named .gconf*.

    One of the symptoms of my problem was, after the user tried to log in
    and failed, there would be some processes owned by that user alive or
    in zombie state but still part of ps output, although of course the
    user was not logged in. These must be killed (or overkilled with
    reboot) and all traces in /tmp removed. But this would show up in the
    log of the machine where user is trying to log in (if I recall) as
    some complaint about gconf. So this may be a goose chase for you,
    since KDE also fails. I'm not sure what (if anything) they would have
    in common.

    Oh well.
    Dave
  • Michael Weiner at Jan 26, 2012 at 3:51 pm

    On Thu, Jan 26, 2012 at 3:40 PM, Thomas Burns wrote:
    If it was me, I'd try creating a new home directory for that user on a
    disk local to the machine where you're trying to log in. Presumably
    the user could then log in. Then I'd check that the user could access
    the NFS share normally just not as home. If no problem there, I'd be a
    bit tempted to stop there as a workaround, because I am lazy and most
    of my users just use one machine.
    I have tried this, but of course i did it as the users $HOME
    directory. The reason we do it this way is because we use that file
    server to then back up all environmental files and user data. This is
    currently working, and has been for years, on other hardware ... we
    just purchased the HP at the end of last year, and silly me thought i
    would just migrate everything over like i have time and time again :(
    Seems possible to me that the dmrc file error message and the instant
    logout are related but not identical. Gnome just does not like NFS
    home dirs. (My experience has been, if the same user is logged in to
    two machines, kablooey!) I used to frequently see a similar problem,
    after a crash or other odd event, where the user could log in but then
    would immediately be logged out with an error similar to your second
    message. I had a magic trick I had to go through to untangle things,
    if you are desperate enough you could try it:
    At this point i supposed i can try anything, this device is not in
    production yet for this purpose so i have some leeway and can play
    somewhat.
    * delete all files in the user's home dir that start with .gconf
    (.gconf and .gconfd).
    * delete all files in /tmp.
    * reboot to make sure all processes release old corrupted files.
    * if feeling paranoid, before having the user try to log in, check
    again as root that /tmp is empty and nothing in user's home dir is
    named .gconf*.
    I basically achieved this same thing by doing an 'adduser newuser' and
    providing it a password which then created the $HOME directory on the
    NFS mount, and then attempting to login to Gnome or KDE as that user
    to no avail - same error
    One of the symptoms of my problem was, after the user tried to log in
    and failed, there would be some processes owned by that user alive or
    in zombie state but still part of ps output, although of course the
    user was not logged in. These must be killed (or overkilled with
    reboot) and all traces in /tmp removed. But this would show up in the
    log of the machine where user is trying to log in (if I recall) as
    some complaint about gconf. So this may be a goose chase for you,
    since KDE also fails. I'm not sure what (if anything) they would have
    in common.
    Thanks for the suggestions on some other things to try.
    Michael
  • Les Mikesell at Jan 26, 2012 at 3:55 pm

    On Thu, Jan 26, 2012 at 2:40 PM, Thomas Burns wrote:

    Gnome just does not like NFS
    home dirs. (My experience has been, if the same user is logged in to
    two machines, kablooey!)
    Gnome doesn't like multiple concurrent logins, period. For example,
    via the console and freenx as the same user. I've sometimes wondered
    if the authors ever saw a multi-headed unix system or used X remotely.
    But that doesn't really have much to do with the automount/nfs
    issue.

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Michael Weiner at Jan 26, 2012 at 4:01 pm

    On Thu, Jan 26, 2012 at 3:55 PM, Les Mikesell wrote:
    Gnome doesn't like multiple concurrent logins, period. ?For example,
    via the console and freenx as the same user. ?I've sometimes wondered
    if the authors ever saw a multi-headed unix system or used X remotely.
    ?But that doesn't really have much to do with the automount/nfs
    issue.
    No, but it broke up my day, LOL
    Thanks!

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos @
categoriescentos
postedJan 26, '12 at 10:46a
activeFeb 1, '12 at 5:44a
posts17
users6
websitecentos.org
irc#centos

People

Translate

site design / logo © 2022 Grokbase