Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Has anyone come across the use of this config for passwd and groups config in nsswitch.conf? Where I'm working I've been told it's been shown to help situations where a group exists both locally and in ldap which was causing issues for group memberships etc. However this config seems to totally mess up nscd which will be aware of the groups and all their members but will not flip the data around to say the user is a member of all it's remote groups.

Initially it seems, given a fully available environment, to be exactly the same as [FOUND=return] which is an implict default between stages anyway. However apparently a lengthy ticket with Redhat resulted in the recommended use of that configuration.

share|improve this question
up vote 4 down vote accepted

In [FOUND=return], FOUND does not exist, so you'll get the default behaviour. You can check in the function nss_parse_service_list defined in nss/nsswitch.c (in the glibc repository).

For reference, this behaviour is:

  • success -> return
  • notfound -> continue
  • unavail -> continue
  • tryagain -> continue

When you introduce [!NOTFOUND=return], it moves to:

  • success -> return
  • notfound -> continue
  • unavail -> return
  • tryagain -> return

So at the first source failing because of an unavailability (permanent or temporary), and only in that case, you'll stop going through services. If the backend doesn't fail, this will make no difference whatsoever. Please also remember that such a [] statement only affects what happens between the source just before it and the source just after it, not further.

If Red Hat considers that there is more to it in an environment that's not fully available, you might want to ask them to explain what that is exactly, and to open a Feature Request against Red Hat Enterprise Linux to get the semantics properly defined in their documentation.

As far as nsswitch.conf(5) and my experience go (and it includes technical support engineering at Red Hat :), that's pretty much all there is to it.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.