11

Possible Duplicate:
Cannot lock '/etc/group' in recovery mode

I have a laptop with Ubuntu 11.10 that is shared between myself and two other family members. My user id was setup as the only "Administrator" on the laptop. The other users were setup as "Standard" users. In my attempt to try to add myself to the user groups for the other users, I somehow deleted myself from the admin groups. I used the "usermod" command from the terminal. I must have neglected to include the proper switches or syntax for the update.

It looks like I successfully added my userid to the group associated with my wife's account. When I use the "groups" command, I can see only my id and my wife's id in the list. I no longer see the "admin" or "adm" groups, and others that used to be listed. When I go into System Settings > User Accounts it looks like my ID is now listed as a "Standard" user. I would like to change my account back to "Administrator", but now I can't.

I did some searches for solutions and found that I would need to boot into Recovery Mode and execute the usermod command from the root session. I was able to successfully boot into Recovery Mode and get to the root session. I was trying to execute the command "usermod -a -G admin user1" to add my id (user1) back to the admin group.

When I execute the command from the root session, I get the error message "usermod: cannot lock /etc/passwd; try again later". I tried preceding the usermod command with "sudo", but it didn't make a difference, same error. I then tried adding a new user using adduser, thinking I would try to create a new userid and make the new userid part of the admin group. I get the same error using the adduser command.

I saw some posts that recommend looking for and deleting files that end in ".lock" in the etc directory. The only file I found was .pwd.lock which I haven't touched.

I am at a loss as to what to try next. I am relatively inexperienced with Ubuntu and Linux, so alot of this is new to me. Any help you can provide would be much appreciated.

1

4 Answers 4

19

I finally figured out why I was receiving the "usermod: cannot lock /etc/passwd; try again later" error message. The root cause of the issue had to do with the fact that when I booted into Recovery Mode, by default the filesystem was mounted as read-only. Because the filesystem was mounted as read-only, the adduser and usermod commands were not able to perform their functions and produced the error message.

What got me thinking the issue was not a file corruption or *.lock related issue was that there were no passwd.lock, group.lock, or shadow.lock files in the /etc folder. Also, I got a different error message when I tried to copy, rename or delete the .pwd.lock file that was in the /etc folder when I was booted into the Root Session in Recovery Mode. I got a different error message, something like unable to rename file read-only. I did some web searching on "Recover Mode Read Only" and came across the following post: http://www.linuxquestions.org/questions/linux-general-1/cannot-edit-fstab-in-recovery-mode-filesystem-is-read-only-540195/.

The post talks about the Recovery Mode being in read-only mode by default. It suggested remounting as read-write to allow changes to be made to files in the /etc folder. So here's what I did to resolve the issue:

  1. Shutdown the computer
  2. Boot into Recovery Mode --After BIOS load, hold down Shift key to access the grub menu --Once in grub menu, select the entry ending in "(recovery mode)"
  3. From the next menu selected option to enter Root Session
  4. At the root session, execute the following command to remount the filesystem as read-write :

    mount -o remount,rw /
    
  5. Execute adduser command to add my userid back to the admin group. Command executed "adduser username admin" where I replaced username with my actual system username. This time I did not receive an error executing the command since the filesystem was mounted as read-write.

  6. Exit Root Session, exit recovery mode, and rebooted.

Once rebooted into Ubuntu, I could see that my userid was now listed as being a member of the admin group, by executing "Groups" command from the normal terminal session. I also verified the same in the GUI by going to "User Accounts" in the Ubuntu System Settings menu. There my userID was also listed as an "Administrator".

I went further to try to replicate my original issue to see if rebooting back to Recovery Mode and skipping Step #4 above (to remount the filesystem as read-write) would reproduce the "unable to lock /etc/passwd" error, and it did. The root cause of the issue had to do with how the filesystem was mounted in Recovery Mode.

It seems odd to me as a new user that booting into Recovery Mode would be read-only by default. Isn't that the idea of recovery, that you would need to make some changes to correct update files, correct issues that would otherwise not be possible as a normal user?

Anyway, I'm just happy to now have at least one user on the computer with Administrator access. Thanks again to all who responded to my issue.

1
  • Same thing happened to me and this fixed it, but no one has answered why the filesystem goes read-only when you boot into recovery mode. Jan 6, 2017 at 3:55
1

You can try to make the /etc/.pwd.lock file empty (nano /etc/.pwd.lock and delete everything) if it is not and use adduser your_user admin from the root session to insert your user back in admin group. This file is to control access to /etc/passwd and /etc/shadow files avoiding simultaneous modifications. It should be empty if none of the files are being modified.

3
  • I looked at the .pwd.lock file and the contents were already empty. The file is a zero byte file. I tried running the adduser command from the root session and received the same error message I listed above. One interesting thing I noticed. I tried renaming the .pwd.lock file using the mv command, e.g. mv .pwd.lock .pwdlockbak. When I ran the command I received a different error, something about being read-only. I checked the permissions on the file and it shows owned by root with Read Write access.
    – BubbaJ
    Nov 17, 2011 at 4:20
  • I moved the file also as a test (same effect as deleting it) and I received no error while adding users in admin group (in terminal with sudo - not tried in recovery console). I suspect the error you are receiving is coming from something else... but no idea what.
    – laurent
    Nov 17, 2011 at 14:10
  • I am unable to execute the sudo command from the command line since my userid is no longer a member of the admin group. My issue is trying to add my user back to the admin group. I think I figured out the reason why I was getting the error message when executing the adduser or usermod commands. See my answer below. Thanks again for your multiple responses, it helped keep me think through the problem.
    – BubbaJ
    Nov 17, 2011 at 15:31
0

Boot into recovery mode, choose the root shell option, and add your user account back to the admin group.

3
  • In my original post above, I mentioned that I already tried this using command "usermod -a -G admin user1" and I still received the locking error. Is there a different or better command I should use to add my user account back to the "admin" group?
    – BubbaJ
    Nov 16, 2011 at 21:41
  • @BubbaJ, if you just tried running usermod as an unprivileged user, then that is what happens. If you still get the error as root, then remove the .lock file.
    – psusi
    Nov 17, 2011 at 14:49
  • Thanks for your responses. I was running the usermod command from the root session under recover mode, so privileges should not have been the issue. That's what was confusing me. I was also not able rename or copy the .pwd.lock file before attempting to remove, so I never tried to remove it. I finally figured out that the initial error message about "cannot lock /etc/passwd and inability to rename or copy the .pwd.lock file were related. I finally resolved my issue. I posted my answer below. Thanks again for your help.
    – BubbaJ
    Nov 17, 2011 at 15:34
0

You should really delete that lock file using the recovery console, although I think you could probably do the same thing by just going into super user mode with the su - command in a terminal within your regular user session. This seems to be a known bug, although the reason it appears is unkown. Check this bug report for more info.

BTW, using sudo on a root session is pointless because sudo just executes a command with root privileges, and if you're already using the system with root you're already executing commands with root privileges.

3
  • Thanks for your response. The bug link above talks about deleting files group.lock, passwd.lock, and shadow.lock. None of these files exist in the /etc folder. The only similar file that exists in the /etc directory is a zero byte file .pwd.lock. The bug report does not mention deleting this file.
    – BubbaJ
    Nov 17, 2011 at 4:15
  • su requires the password on the root account, which is disabled by default in Ubuntu.
    – psusi
    Nov 17, 2011 at 14:44
  • I was able to resolve my issue. See my answer below. Thanks again.
    – BubbaJ
    Nov 17, 2011 at 15:37

Not the answer you're looking for? Browse other questions tagged .