unable to lock password file
 

Hello. I use webmin to manage my Red Hat based server. I've been having some problems with WU-FTPd timing out and so, following some advice from a newsgoup, I deleted the contents of /etc/resolv.conf. Well, this fixed the timing out problems with WU-FTPd but it killed all my users, groups and passwords. I can restore them by copying everything from the passwd- (etc.) files back into the original containers. Now however, whenever I try to add a user to my machine webmin deletes the contents of my passwd, group and gshadow files and gives me a message saying that I don't have rights to edit goups or users. Restoring the contents of these files makes everything work again. When I try to add a user with useradd I get a message like "unable to lock password file." What's going on with my box? I restored the contents of resolve.conf but still nothing.

Thanks
Ryan

Could you tell us *exactly* which commands this particular NG post offered, and what you did?
Barring weird options if you fancy those, /etc/resolv.conf usually only contains the nameserver <ip> pairs. You need access to those to be able to resolve for instance your hostname (IIRC libnss*/ /etc/nss*.conf relies on those).

An error like "unable to lock password file" would be typical for where you try to access those files as an unprivileged user, which leads me to believe there's more amiss than "only" the mucking around with the resolv.conf, so again, tell us *exactly* which commands lead up to this. Also have a quick go at verifying your system's rpm's. To get an overview use you bash history file if you did it from the cmdline, webmin logs and system logs.

I deleted the nameserver IP addresses in the file. My box dosen't have a domain name anyway. This fixed WU-FTPd's little speed hang up. The error messages I get from useradd is "unable to lock password file." group, pass and shadow all have lock files which contian PID 1929 which of course dosent' show up when I display all running processes. Still, whenever I use Webmin to add a user it wacks contents of the pass file. The file's still there it's just empty. If I try to add a user from the command prompt I just get the error message.

Thanks,

Ryan

Hmm. Next time you get advice you should verify it using some other source. And you should really read up on the basics of networking.

Let's try to handle this methodically:
First determine user, then fix resolv.conf, then verify systems passwd files. Local or remote box? We need to know if your box is local or remote. In both circumstances you should work from X/the cmdline but not webmin. If it's remote I hope you have other means of access like ssh.

Determine user.
On the commandline type "whoami" and "id". If you're root this should return "root" and uid=0(root) etc, etc. If not, sudo/su in as root or relogin as root, recheck and try to add a user as a test. If you *are* root and you can't still work the passwd files you've got a rather large problem. Shut down all unnecessary services before you try to determine the problem (that's all except the stuff you need to access the box with, like ssh if it's remote).

Fix your resolv.conf.
The IP addresses in resolv.conf (the "order" directive in host.conf and the info in nsswitch.conf) are there to help the system resolve local and remote name/addresses using (external) domainname servers. If this system is connected to (a network having access to) the internet you need to have the nameserver addresses in resolv.conf, either a local DNS server or your ISP's DNS servers.
If this is a local box, I would suggest closing down webmin and fixing the problem before restarting it. If not local I would suggest closing down webmin anyway and ssh in, adding the info in resolv.conf, `chattr +iu /etc/resolv.conf`, restart the network to reread the info, and then start webmin up again (this could be done from a script). The chattr part will disallow webmin to change the contents of the file, note you can't do this with like passwd files if you have to delete/add entries from 'em.

Determine state of the system.
Next you should be able to recheck again who you are logged in as on the system and test passwd access.
If not, reboot the box. When rebooted, as a precaution you first should run chkrootkit(.org), (and if you where cool enough to install Aide or Tripwire, check their logs and rerun). Then save and verify the contents of passwd and group (and shadow) with a backup, restore if necessary, disable user accounts you don't need. If you restore, reboot the box. Next save and check your system's logs for *any* weird behaviour (just to be sure) and check the access records. Next verify your installed rpm's pay attention to changed md5sums in binaries.
If you reboot, rerun the user checks. If your user=0 check still fails and you still cant work the passwd files this should be suspicious to you. But we'll get to that state when you reply.

HTH, please reply as verbose as you can.