Issue: RHEL 5 NIS Client Automounting ALL User Directories
 

I have RHEL 5.8 NIS clients calling on a Solaris 10 NIS server. Many of the RHEL NIS clients will mount ALL NIS users' home directories EVERY five minutes.

Some process is calling on users' and automounting their home dirs. If I restart 'autofs' they umount, then in 5 minutes they mount up again.

At first I thought it was NetBackup crossing mount points, or Sendmail emailing EVERYONE. But it's not those. I've watched performance during the 5 minute interval to see if I could find the process doing this. I cannot find it.

Maybe some auditd process?

These are pretty basic servers with NO GUI desktops on them.

I've checked all /etc/cron*/ entries and "crontab -l" entries.

Does anyone know a way to see what might be causing this?

Has anyone see this before?

On the plus side, I have NO PROBLEM mounting NIS home directies. :-)

If I limit the /etc/auto.home file to specific admins, then only they get their home dirs mounted to the NIS file server. But that's not finding the cause.

Thanks for any suggestions.

Bummer. Not even on weak reply or guess. I suppose that's something.

I found a little time today to troubleshoot this issue, but I've not found the cause of home dirs automouting.

I'm sure it's something we've done that's not directly related to RHEL, but I'm not certain yet. We're fairly new to RHEL as we've been in Solaris-land forever.

I was thinking it might be a cron of other service, but nothing proves to solve the issue yet.

I've tried temporarily turning off crond, snmpd, snmptrapd, auditd, and a few others. The NIS user dirs keep mounting every 5 minutes. Of course restart/killing autofs corrects the problem.

I've just never seen this type of behavior in Solaris. It's our first time using NIS on Linux. I guess this is why I decided to test a few servers before relying on it heavily. It's a closed private network that's why we've chosen to stay with NIS to help serve out developer/admin authentication.

I'll update this WHEN I find the culprit, even if it's our own configuration/scripts somewhere, which I'm sure it must be.

:-|

Thanks,

bits45