/etc/group and /etc/passwd corrupted

My /etc/group and /etc/passwd (and possibly others) are corrupted (my silly error handling pacnew files). I tried restoring the backups (group- and similar) and also ran grpconv, pwdconv,, pwck without fixing things.  I've edited the files, using those in another machine as a template but no luck.
Various commands (e.g. ssh) fail with the message:
                                 No user exists for uid 1000
Before I give up and reinstall, is there any way I can restore things to how they should be?

Thanks for replies. I can't recreate my user because it's already there. I can log in as ac without difficulty and do most things - just a few (mportant) fail.
I don't understand why it keeps saying the user ac is uid 1000. After reading the wikis I think my /etc/group and /etc/passwd are correct. /etc/passwd has:
            ac:x:1000:100::/home/ac:/bin/bash
and /etc/group has:
           users:x:100:ac
           ac:x:100:ac
I'm not sure the last line should be there, but removing it doesn't help. The entries on a second machine are similar.
I'll sleep on it to see if I think of something else to try in the morning, otherwise I'll have to reinstall tomorrow.

Similar Messages

  • [SOLVED] Today's update of /etc/group, /etc/passwd and /etc/gshadow

    Hello,
    During the regular updates I received an update of /etc/groups. I wonder what I should do here, as there are some differences between the old file and the pacnew one. I suppose that when I use the command to add my user to a group, it gets written into this file. So, just recklessly moving the pacnew file in the place of the old one, will mess up all my groups, won't it?
    Then what should I do? All the entries in the pacnew file are also present in the old one, so I guess I could just delete the pacnew one and keep the old one. Am I right?
    EDIT: The same goes to /etc/passwd and /etc/gshadow.
    Last edited by Unia (2012-10-06 09:51:23)

    teateawhy wrote:
    If you had the uuid user before like me the uuid line in your own files is different from the pacnew file. You have to delete the uuid line near the bottom in your old file. Then insert the new uuid entry including the new number in the place near the top suggested by the pacnew file. Keep the other lines untouched, then save your changes and delete the pacnew files.
    Edit: On a system that has actually been modified from a default install the new files will for sure be different to the old ones.
    Thanks, teateawhy!  I currently have this listed in /etc/passwd:
    uuidd:x:998:998::/:/sbin/nologin
    And this is in the .pacnew file:
    uuidd:x:68:68:uuidd:/:/sbin/nologin
    So, I can just copy the entry from the .pacnew file, overwriting the old entry, right?
    What I don't understand is how the two numbers 998 representing the UID and GID can suddenly change to 68.  Shouldn't they have to correspond with some other reference or list of users/groups...?
    I'm sure it's fine to just replace the entry as you suggested, but I wondered if there was a way to double-check which uid/gid should be used?  It's not that I don't trust you, but I don't fully understand how these group/passwd files work and I'm trying to get my head round it all.
    Cheers,
    esuhl

  • [SOLVED] /etc/passwd and /etc/shadow -- pwck shows missing groups

    I recently found out about the pwck and grpck commands to check for errors/inconsistencies in the passwd, group, shadow and gshadow files...  grpck returns no errors, but pwck returns this:
    user 'avahi': no group 84
    user 'postgres': no group 88
    user 'ntp': no group 87
    pwck: no changes
    These are the relevant lines from /etc/passwd:
    avahi:x:84:84:Avahi daemon:/:/bin/false
    postgres:x:88:88:PostgreSQL user:/var/lib/postgres:/bin/bash
    ntp:x:87:87:Network Time Protocol:/var/lib/ntp:/bin/false
    There are lines for those users in /etc/shadow... but...  I'm not sure what I need to do to fix the problem.
    I think I understand enough, now, to maintain the files in future, but would anyone know I can fix this?
    Last edited by esuhl (2012-10-08 20:22:05)

    2ManyDogs wrote:I don't know how to fix the errors, but I'm really curious about why you decided to run those commands. Were you having a problem you thought might be ralated to groups and/or passwords? What are groups 84, 97, and 88?
    Ha!  Well... when I started using Arch I really didn't know much about Linux and I an update providing some .pacnew files (/etc/group, gshadow, passwd, shadow) and... well...  I don't know what I did, but I think it was probably not what I should have done(!).  I used grpck in the past and got no errors and it suddenly occurred to me today that there should be an equivalent for checking /etc/passwd... so that's why I just ran the commands now.  Everything seems to be working, however...
    I don't have an entry for groups 84, 87 and 88 in my /etc/group file...  Hmmm...
    I tried running this command to find any files associated with that group, but only get the following:
    [root@i7pc tim]# find / -gid 88
    find: `/run/user/1000/gvfs': Permission denied
    find: `/proc/1806/task/1806/fd/5': No such file or directory
    find: `/proc/1806/task/1806/fdinfo/5': No such file or directory
    find: `/proc/1806/fd/5': No such file or directory
    find: `/proc/1806/fdinfo/5': No such file or directory
    I get similar output for the other groups, so... can I just delete them from /etc/passwd and /etc/shadow?
    I notice I have the avahi package installed, however, and group 84 relates to user 'avahi'... so...  surely I need the avahi user...?
    Last edited by esuhl (2012-10-07 23:09:30)

  • Systemd entries in /etc/passwd and others...

    Hi! How do I find out what are correct entries for systemd in /etc/passwd, /etc/group, /etc/shadow and others in current system? What if I screw them up during system update and maybe lose some of them or will end up having those unneeded?...

    I don't understand what you want. A backup maybe? Do you have any pacnew files?

  • Smc and smuser both put wrong home directory in /etc/passwd

    Hello,
    I'm trying to use 'smuser add' as an alternative to 'useradd' in a setuid script, using -d to specify a home directory other than the default. Unfortunately, although the directory is created in the right place, the default is written into /etc/passwd.
    %smuser add -u sapadm -p ***** -- -d /appuser/inputs/tom -g sapusers -n tom -s /bin/sh
    Loading Tool: com.sun.admin.usermgr.cli.user.UserMgrCli from localhost
    Login to localhost as user sapadm was successful.
    Download of com.sun.admin.usermgr.cli.user.UserMgrCli from localhost was successful.
    % ls -al /appuser/inputs/tom
    total 14
    drwxr-x--- 2 tom sapusers 5 Mar 28 15:48 .
    drwxr-xr-x 3 sj staff 3 Mar 28 15:48 ..
    -rw-r--r-- 1 tom sapusers 136 Mar 28 15:48 .cshrc
    -rw-r--r-- 1 tom sapusers 157 Mar 28 15:48 .login
    -rw-r--r-- 1 tom sapusers 174 Mar 28 15:48 .profile
    % cat /etc/passwd
    tom:x:101:1002::/home/tom:/bin/sh
    % ls -al /home/tom
    /home/tom: No such file or directory
    % uname -a
    SunOS sun03 5.10 Generic_127112-07 i86pc i386 i86pc
    Exactly the same thing happens when I use the SMC2.1 GUI - even though it echoes back to me that the directory path qill /appuser/inputs before I hit 'finish', the directory is created correctly, but /home/tom goes into /etc/passwd.
    Is there any fix/workaround for this, or am I back to an old-fashioned useradd in a setuid script?
    Thanks
    -- Steve

    Father wrote:
    that way, they are chrooted into an empty directory and have no files they can tamper with
    isnt that a little dangerous??
    What files a user can change is determined by the files' permission settings, not by the user's homedir. The homedir only tells what the initial working directory when a user logs in is, nothing else, it doesn't implicit writing or even reading access. So no, it's not dangerous, not even a little.

  • Login Process & Security of /etc/passwd and /etc/shadow

    Guys,
    I have few questions, Please help me out.
    1. What is the Solaris 8 and Solaris 9 environment's boot files ?
    2. While Logging into Solaris Operating Environment , which is file is responsible for Login Process ? Through which file/command the username and password is cross checked with /etc/passwd and /etc/shadow ?
    3. We all know that /etc/passwd come with -rw-r--r-- permission and /etc/shadow comes with -r--------. I did a chmod and assigned 000 to both the files. But Still I am able to change the password for the normal user. And as a root I am still able to cat the contents of both the files.
    Help me understand these concepts.
    Thank you.
    Arut

    Sounds like you're very new to Solaris:
    1. What is the Solaris 8 and Solaris 9 environment's boot files ?/kernel/genunix is the primary boot file. The directory structure in /kernel is also boot related. /usr/kernel is also boot related.
    2. While Logging into Solaris Operating Environment , which is file is responsible for Login Process ? Through which file/command the username and password is cross checked with /etc/passwd and /etc/shadow ?Generally three files are related: /etc/passwd, /etc/shadow, and the program /bin/login. Some applications will process /etc/passwd and /etc/shadow on their own and bypass /bin/login - but for you're purposes this is a good general answer.
    As a minor example (and if I remember correctly), say someone uses telnet to log into a system. Telnet prompts for the login ID. Once input, it passes forks off /bin/login with the login ID. /bin/login reads the user password information from /etc/shadow and takes the first two bytes from the password field (column 2 using : as field seperator) which is the crypt salt (see crypt man page). /bin/login prompts for the password which the user inputs. /bin/login takes the user input password and the salt value read from /etc/shadow for that user and pushes it through crypt. It then takes the resultant crypt output and compares it against what it read from /etc/shadow - if they matches the user has input the right password. If not, it prompts the user again with a password prompt.
    3. We all know that /etc/passwd come with -rw-r--r-- permission and /etc/shadow comes with -r--------. I did a chmod and assigned 000 to both the files. But Still I am able to change the password for the normal user. And as a root I am still able to cat the contents of both the files.To change your password you run the passwd command. That command is SUID root - so for a short period of time you become root within the context of that process. Root is basically god mode and doesn't care about file access priviledges generally. So that fact that /etc/passwd and /etc/shadow have 000 file access permissions doesn't matter - root can still read and write to them.

  • How to recover /etc/passwd and /etc/shadow files

    hi
    Unfortunetly I have a big problem is that someone crash the /etc/passwd and /etc/shadow files from my running server, and my all users are not to able to login. so please can any one help me how to recover this files or any ideas for make these files...
    thanks
    Mohammed Tanvir

    Hello
    It is not working.Pla help me this bit critical
    Step followed
    01.Boot from the cdrom and mount root partision.
    02.Deleted the exsisting file /etc/passwd and /etc/shadow
    03.copy the opasswd and oshadow to the etc directory as passwd and shadow
    04.Umount the root partision
    05.Reeboot the system
    thanks
    Roshantha

  • Deleted my /etc/groups and /etc/gshadow and now no mouse and keyboard.

    Hey.
    So a few days ago I updated my system and did something we all know to avoid. I accidently moved the empty .pacnew files over my groups and gshadow files so my entire group layout is out of the window. I am an idiot I know. My mom told me that when I was six. So I am now looking at fixing my system. My biggest problem is that now xorg runs but the keyboard and mouse don't respownd. This isn't a USB problem since I tried using non USB keyboard. In runlevel 3 keyboard works fine.
    Xorg.log says something about input bring used by someone else  so my guess based on the above is that what I need to do is restore my old groups since its probably a group ownership problem. My question is if anyone knows which groups should I restore and how does one go about repairing the Damage? I would be thankfully to anyone who would take the time saving me from my own stupidity.
    Last edited by Greenstuff (2012-08-22 08:03:26)

    This might be the solution. Perhaps I should post my /etc/group file and you can fix yours? I don't know, did you ensure that all your groups have the correct GID?

  • How to Add DNS Compatibility and +/- in /etc/passwd

    Hi Guys,
    can you tell some thing about adding + - in /etc/passwd, group for DNS Compatiability.
    thanks,
    susesun

    See the nsswitch.conf(4) manual page.

  • [Solved] Questions about /etc/group and /etc/gshadow

    This morning, package filesystem was upgraded to 2015.02-1 and pacnew files were created for /etc/group and /etc/gshadow. I ran diff against my current files, and the differences seem very minor, to me. I need some guidance to understand whether I should implement the pacnew changes.
    The only significant difference I see in the group file is that in my original version, my username is added to the wheel group. This seems correct, to me.
    For gshadow, there is the same difference for wheel. However, there are several entries where my original entry contains an exclamation point, but the new version does not. For example:
    < proc:!::
    > proc:::
    If I run man /etc/gshadow, it does not give me what I understand as a man page, and gives me what appears to be a listing of the stuff in my /etc/gshadow file, instead. Which does not help me.
    So, like I say, I need some guidance on dealing with these pacnew files.
    Tim
    PS - I now see that "man gshadow" gives me an actual man page. Sorry. I am currently studying it.
    Last edited by ratcheer (2015-02-24 21:37:52)

    After the update to filesystem 2015.02-1 some voices in /etc/gshadow were changed (in the pacnew file) from
    systemd-journal-gateway:!::
    systemd-timesync:!::
    systemd-network:!::
    systemd-bus-proxy:!::
    systemd-resolve:!::
    to
    systemd-journal-gateway:::
    systemd-timesync:::
    systemd-network:::
    systemd-bus-proxy:::
    systemd-resolve:::
    What's the change? Before they had a locked password (the ! sign) and now they haven't?

  • New /etc/passwd.shadow

    I have seen that with an upgrade I have an /etc/shadow.pacnew From what I know it is only a shadow copy of /etc/passwd without the password and can simply be generated by pwconv (similarly /etc/group.shadow can be generated by grpconv). So my question is why archlinux proposes me /etc/shadow.pacnew? What I did is simply fix the new /etc/passwd that were also proposed, rm the /etc/shadow.pacnew and run pwconv. If this is really the good thing to do, /etc/shadow.pacnew shouldn't have been proposed.

    olive wrote:I think most of you do not understand my point. I do not understand why /etc/shadow has to be shipped in the first place. It would be best to just ship /etc/passwd and to generate /etc/shadow automatically by pwconv. There are a lot of such files that can be automatically generated and such files are in general not included in the package.
    I ran pwconv and now I have two entries for dbus in /etc/shadow:
    I manually megerd the shadow.pacnew and had en entry for dbus
    dbus:x:14871::::::
    after running pwconv I have two entries for dbus:
    dbus:x:14871::::::
    and
    dbus:x:15686:0:99999:7:::
    I assume there arnt ment to be two?
    *EDIT
    Seems either works? I dont get any problems either way (I dont think)
    But, I think that:
    dbus:x:15686:0:99999:7:::
    was the original entry for dbus before the pacnew anyway?
    Last edited by jrussell (2012-12-12 00:33:27)

  • System.getProperty("user.name") not working without /etc/passwd, CentOS 4.3

    Dear all,
    I'm having trouble getting the system property user.name (which we need in our ant scripts) on our CentOS box. :(
    When running the program below thru
    java dumpproperties2
    it prints "user.name='?'" on our CentOS 4.3. On win32 it works. It turns out that if you add the account corresponding to the EUID to /etc/passwd it works correctly. However, we don't use passwd authentication but an enterprise wide LDAP-system. Our /etc/nsswitch.conf says:
    passwd: files ldap
    One work around is to replace the java executable with a script that does
    /path/to/jdk/bin/java -Duser.name=$USER -Duser.home=$HOME $@
    Used jdk is j2se 1.5.0_13 Linux 32-bit.
    Some questions for the experts:
    1) Is there any other way?
    2) Is it a known issue that Linux versions of the jdk just looks in /etc/passwd to map uid to user name (and home dir) instead of doing what the rest of the system, like whoami, does? I haven't found anything in either the readme or installation instructions, nor in the bug db.
    Br, Jesper Tr�g�rdh
    public class dumpproperties2 {
        public static void main(String[] args) {
         String s = System.getProperty("user.name");
         System.out.println("user.name='" + s + "'");
    }

    Does this work?
    //public final class System
    public static String getenv(String name)Then you can access the USER environment from inside Java.

  • How to handle home directory change in /etc/passwd.pacnew?

    Hey,
    the recent update of the filesystem package had a change in /etc/passwd that
    I am not sure how to handle:
    daemon:x:2:2:daemon:/sbin:/usr/bin/nologin
    was changed to
    daemon:x:2:2:daemon:/:/usr/bin/nologin
    As you can see, the home directory of daemon was changed from /sbin to /.
    Should I merge that change into my /etc/passwd?

    I have read that thread but I am not quite sure that it applies to
    this situation.
    Leonid.I basically says that
    [...] if your group/passwd files are functional before the update -- keep them as is
    (unless you wan to do cosmetic changes)
    Now, adding info to the GECOS field or substituting /sbin with /usr/bin
    doesn't really alter the behaviour of the system, but changing a user's
    home directory seems a little bit more fundamental to me.

  • Modifying /etc/passwd to run a script (with logging)

    This is not Arch related so feel free to ignore...
    The goal is to modify a users /etc/passwd entry so it runs a script instead of a shell.
    As a proof of concept, this works:
    #!/bin/bash
    read -p "Enter your selection: " selection
    case "$selection" in
    1) /usr/bin/ssh [email protected];;
    *) exit 0;;
    esac
    If I su to a user with that as their "shell" I see the prompt, I can press 1 and login to the remote box
    Then I thought I'd try to add some logging and script became this:
    #!/bin/bash
    read -p "Enter your selection: " selection
    case "$selection" in
    1) /usr/bin/script -c "/usr/bin/ssh [email protected]";;
    *) exit 0;;
    esac
    This does work when run directly at the command line but does not work when set as a users shell in /etc/passwd... it's like it executes the script over and over again.  The output is:
    Enter your selection: 1
    Script started, file is typescript
    Enter your selection: 1
    Script started, file is typescript
    So adding the /usr/bin/script to the mix is causing a problem.
    What is the cause?  I'm assuming it's something to do with subshells but I thought the '-c' would resolve that.
    How can I make it do as expected (without modifying .profile if possible.)  The end-goal is for users to log in and be presented with a list of servers to connect to
    Is there a better way to accomplish this?
    Last edited by oliver (2015-01-20 16:38:11)

    I'm trying to avoid modifying profiles due to the archaic way we handle user accounts at work... it would be one more thing to maintain but it's certainly not impossible.
    I think I will switch to /bin/sh anyway - just used bash out of habit
    And reading the first post back, I'm not sure it's entirely clear... but it works at the command line and only fails when it's set as a user's shell.  I'm not sure what the difference is
    Last edited by oliver (2015-01-20 16:51:48)

  • Passwords for users listed in /etc/passwd

    Do the predefined users listed in the /etc/passwd file have default passwords? The entry for each user password is *. Does this mean that the password is hidden or that it does not exist? In particular does the mysql user have a default password?
    Any help would be most appreciated.
    PowerPC G5   Mac OS X (10.4.6)  

    An entry with a single * means that the account's password is invalid, and therefore nobody can log into that account if a password is required to do so. More information is available in this article.
    (11862)

Maybe you are looking for