One account can log in; another can't, and its cron jobs silently fail — while everyone else is fine. A malformed line in /etc/passwd is a classic cause: a wrong shell field, a missing colon, or a mangled UID breaks just that entry.
Find the bad entry
getent passwd deploy # inspect the 7 colon-separated fields # name:x:UID:GID:GECOS:home:shell grep deploy /var/log/auth.log # "invalid shell" / "cannot open session"
Each line must have exactly seven fields. The last one — the login shell — must be a real executable listed in /etc/shells; a typo'd path there means the account can authenticate but gets no usable shell, which breaks interactive logins and cron sessions alike.
Repair it with vipw
vipw # edits /etc/passwd with locking + a sanity check (like visudo) # fix the shell field, e.g.: # deploy:x:1001:1001:Deploy:/home/deploy:/bin/bash
Use vipw (and vipw -s for /etc/shadow) rather than a raw editor — it locks the file so a concurrent useradd can't corrupt it further.
Practise it
Account-file corruption is one of the simulator's access-control incidents. Drill it in Linux troubleshooting practice.