'Account has expired' message when adding a new user, after "passwd -l root"

Me too. I have this problem with adduser from the time when I enabled the root user (sudo passwd root) and then disabled it (sudo passwd -l root).
Hope this info will help.

I have the same error, when trying to use chfn. This also has the neat effect, that it breaks installation of mysql-server, as the pre-install script fails.

This is the command, which fails during the mysql-server pre-installation script:
$ sudo /usr/bin/chfn -f 'MySQL Server' mysql
Your account has expired; please contact your system administrator
chfn: PAM authentication failed

I get the same error when trying to chfn any other user or use adduser:

$ sudo adduser foobar
Adding user `foobar' ...
Adding new group `foobar' (1001) ...
Adding new user `foobar' (1001) with group `foobar' ...
Creating home directory `/home/foobar' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Your account has expired; please contact your system administrator
chfn: PAM authentication failed
adduser: `/usr/bin/chfn foobar' returned error code 1. Exiting.

I too started with a non-disabled root acount, because I installed Ubuntu via debootstrap (no dmraid support in any of Ubuntu's installers).
Thus I locked the root account via 'passwd -l root' later just as aledin did.

Changing the package from 'adduser' to 'shadow' as the actual command which fails is /usr/bin/chfn which originates from the shadow source package.

Forgot to mention: The error is _not_ there when I unlock the root account with 'sudo passwd root'. chfn fails only when root is locked via 'passwd -l root'.

I don't think there is a bug. This looks like a configuration issue.

When it is called, chfn authenticates the calling user (root), and then check if the calling user's is valid.

Being root is sufficient to get authenticated (pam_rootok is loaded in /etc/pam.d/chfn), but /etc/pam.d/comman-account will still check that the account is valid, and in your case it is no more valid (because of the passwd -l root)

You should unlock the root account (passwd --unlock root), then lock the root's password (usermod --lock root)

Yes, this is an configuration issue. By default Ubuntu's root account is disabled and chfn should surely handle this configuration and just work. But it does not.

https://help.ubuntu.com/community/RootSudo tells to execute 'passwd -l root' to "re-disable" the root account. As I understand it this is Ubuntu's default configuration and chfn fails to work with it.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389183

it has been changed in debian that way.
Don't know if it has been intentional introduced to Ubuntu.

the original intention of upstream has been to prevent ssh access where the user has been locked.

Maybe a solution is to advance the patch to expire the account only if $USER != root

That way the original intention is preserved without this somewhat regression.

PS. Debian users also stumpleupon this change:
http://thread.gmane.org/gmane.linux.debian.user/330437

Seems to me that chfn should not be trying to reauthenticate the calling user. Authentication is handled by the login program, so it should not also be done by chfn.

A user that is unable to login for any reason ( could also just not be allowed on this tty or something ) should still be able to chfn.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492307

http://thread.gmane.org/gmane.linux.debian.devel.release/21922

This means in debian it will be fixed shortly.

SRU anybody?

packages.debian.org already has passwd 1:4.1.1-3

changelog (the parts that matters here):

   * debian/patches/494_passwd_lock-no_account_lock: Restore the previous
     behavior of passwd -l (which changed in #389183): only lock the user's
     password, not the user's account. Also explicitly document the
     differences. This restores a behavior common with the previous versions of
     passwd and with other implementations. Closes: #492307

summary:

* cronjobs are broken for system that has a 'passwd -l root' with hardy
   http://thread.gmane.org/gmane.linux.debian.user/330437

* the implematation of the patch that changed 'passwd -l' is broken:
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492307

* + the confusion it causes at users-side due to unexpeted behaviour.

All of this is fixed in debian now. For hardy this all is imho a serve regression.

Pls devs fix it.

The importants of this bug has been set to high and the number of duplicates is staty growing.....

A workaround for those who are affected:
$ sudo vim /etc/shadow

change the line:
root:!:13919:0:99999:7::1:

to
root:!:13919:0:99999:7:::

You have to redo this everytime you use 'passwd -l $USER' as long this bug is not fixed.

Worked around this problem in landscape-client by not passing --gecos to adduser.

This bug was fixed in the package landscape-client - 1.0.25-0ubuntu0.9.04

---------------
landscape-client (1.0.25-0ubuntu0.9.04) jaunty; urgency=low

  * New upstream release supporting custom graphs (LP: #306360)
    - Multiple custom graphs can be used at the same time (LP: #307314)
    - PATH is now set for scripts in script execution (LP: #257018)
  * debian/landscape-common.postinst: Only chown parts of /var/lib/landscape
    because we now store files in it that should maintain their ownership
    (LP: #307321).
  * debian/landscape-client.postinst: Work around chfn/system user problem
    by not specifying a --gecos (LP: #238755)
  * debian/landscape-client.logrotate: logrotate no longer reports spurious
    errors when the client isn't running (LP: #271767)

 -- Christopher Armstrong <email address hidden> Thu, 11 Dec 2008 17:11:08 -0800

I would strongly suggest using 'sudo vipw -s' instead of directly editing /etc/shadow. It's a wrapper that makes sure you don't accidentally introduce syntax errors and break your whole system.

good point. how about fixing the damn thing instead of another less risky workaround?

ok it doesn't get fixed. nice day.

It seems that the updated package will not install. Getting this error in Synaptic:
E: landscape-common: Package is in a very bad inconsistent state - you should reinstall it before attempting a removal.

Is this related?? Ric

Whoops, sorry. I'm running Kubuntu Jaunty with installed package not upgrading from 1.0.29.1Obuntu0/9.04.0 to 1.0.29.1Obuntu0/9.04.1

I hate messages like this. :) Ric

On Fri, Jul 17, 2009 at 07:31:28AM -0000, wayward4now wrote:
> It seems that the updated package will not install. Getting this error in Synaptic:
> E: landscape-common: Package is in a very bad inconsistent state - you should reinstall it before attempting a removal.

Doesn't seem related - that sometimes happens if e.g. you have a power
failure in the middle of installing packages. In general finding the
landscape-common .deb and running 'dpkg -i
/path/to/landscape-common.deb' (and then successively dealing with any
error messages that that in turn throws up; 'dpkg --configure -a' may be
useful, for instance) will deal with this.

On Fri, 2009-07-17 at 08:38 +0000, Colin Watson wrote:
> On Fri, Jul 17, 2009 at 07:31:28AM -0000, wayward4now wrote:
> > It seems that the updated package will not install. Getting this error in Synaptic:
> > E: landscape-common: Package is in a very bad inconsistent state - you should reinstall it before attempting a removal.
>
> Doesn't seem related - that sometimes happens if e.g. you have a power
> failure in the middle of installing packages. In general finding the
> landscape-common .deb and running 'dpkg -i
> /path/to/landscape-common.deb' (and then successively dealing with any
> error messages that that in turn throws up; 'dpkg --configure -a' may be
> useful, for instance) will deal with this.

THANK YOU! That did the trick! I used to work for RedHat, back in the
Bob Young days, as Installation Support Eng. So, I'm still learning the
ropes with apt-get. Fedora went past the point of audience participation
until I had to just quit using it. Bob would have never treated his
users like that. It was like getting a divorce. But, when I read Mark
Shuttleworth's philosophy, it was like being back in the old days of
RedHat. I hope you guys stay true to that vision. You taking the time to
reply is proof that you are. thanks! Ric

--

My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
Linux user# 44256
https://nuoar.dev.java.net/
Verizon Cell # 434-774-4987

Intrepid Ibex reached end-of-life on 30 April 2010 so I am closing the
report. The bug has been fixed in newer releases of Ubuntu.

This bug is still present in 10.04.2. My cronjobs as root were failing with "Authentication failure" messages in /var/log/syslog. I had use the same edit of /etc/shadow mentioned earlier in this post to fix the problem.

Status changed to 'Confirmed' because the bug affects multiple users.

Thank you for reporting this bug to Ubuntu. hardy has reached EOL
(End of Life) for this package and is no longer supported. As
a result, this bug against hardy is being marked "Won't Fix".
Please see https://wiki.ubuntu.com/Releases for currently
supported Ubuntu releases.

Please feel free to report any other bugs you may find.

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".