If you create a user without a home on Arch Linux with useradd -M test, an entry like the following is created in /etc/passwd:


But because /home/test doesn't exist, this causes shadow.service to fail. Leaving the home directory blank will produce the same error. I found an old thread suggesting to use /dev/null, but I'm not sure if that's the best solution. ATM, ignoring it seems like the best solution, but maybe there is a better way.

shadow.service boils down to pwck and grpck:

### [...]
ExecStart=/bin/sh -c '/usr/bin/pwck -r || r=1; /usr/bin/grpck -r && exit $r
### [...]
  • you'll find other accounts in /etc/passwd which do not require or should have a home directory (which is nothing new) and I believe the proper method or convention to do such a thing is with either /bin/true or /bin/false specified as the home directory.
    – ron
    Nov 2, 2020 at 1:27
  • 1
    Maybe I'm missing something, but what you are referencing is about the shell and not the home. (usermod) -s specifies the shell. /bin/false would be a regular file, that could cause issues (try cd /bin/false). However upon closer inspection, many stock nologin users have just / as their home...
    – rudib
    Nov 2, 2020 at 1:42
  • yeah you are correct,
    – ron
    Nov 2, 2020 at 1:47

1 Answer 1



If you are on a Debian-based system, the new - already somewhat present by default in multiple debian-based distributions, (as well as already included in the source code of both pwck and login.defs of the next shadow-utils package release) proper way to account for nonexistent home directories is with the /nonexistent path.

If you actually get the newest shadow-utils package , it will allow you to configure your /etc/login.defs and add (or uncomment) the following option:

This is from the new man 8 pwck from the latest commit:

   NONEXISTENT (string)
      If a system account intentionally does not have a home directory
      that exists, this string can be provided in the /etc/passwd entry
      for the account to indicate this. The result is that pwck will
      not emit a spurious warning for this account.

and the actual option belongs in /etc/login.defs like so

# The [string] can be whatever word/path you want to use in your /etc/passwd file to
# correspond to a nonexistent directory. However, /nonexistent should be used as the default 
# nonexisting home directory, as that is already in use in many distributions. 


This option has been added specifically for pwck to account for nonexistent home directories, which is the underlying command used by the shadow.service that checks the validity and integrity of /etc/passwd using the configuration provided in /etc/login.defs.

If you do use this configuration option, then using sudo adduser -M -d /nonexistent [username] followed by pwck -r will not throw an error.

Other distributions

While many Debian-based distributions already use this approach for this particular situation, there are other variants which use their own system to account for nonexistent home directories.

However, you can usually test how your distribution already determines the nonexistent home directory situation, by executing

sudo grep nobody /etc/passwd

as this particular non-privileged user will never by default have its own home directory path, yet the corresponding value found in your /etc/passwd will give you a clue of how your system already deals with it.

For example:

  • RHEL/CentOS uses / as a fail-safe for home directory of nobody yet disables its login shell through /sbin/nologin

  • Debian-based distros currently use /nonexistent for home directory, and /usr/sbin/nologin for the shell

  • SUSE Linux, until at least mid 2019, used /var/lib/nobody for the directory and /bin/bash for the shell, but some security-conscious memos suggest a change to /var/lib/nobody and /bin/false

  • OSx used and might still use /var/empty and /usr/bin/false for nobody

  • I have encountered other distributions that use /nonexistent yet allow for shell with /bin/sh

The issue with using sudo useradd [username] is that it specifically allows for system preset options in /etc/login.defs to be overwritten at execution, even if they may violate the integrity of /etc/passwd.

I have not tested useradd in a while, but - unless significant changes have been made to the source code - the validator for the -d option flag had many limitations. There was certainly a check present for whether optarg[0] of the provided path is indeed / and whether a path contains : but every test I ran using * , and hence I would not be surprised if sudo useradd -d /home/my:base [username] actually executed without error.

  • It looks like arch hasn't adopted NONEXISTENT yet. So I guess it would have to be a real directory until then. Thanks a lot!
    – rudib
    Nov 2, 2020 at 10:01
  • I might add to this that while RHEL/CentOS does not seem to have NONEXISTENT /nonexistent set in /etc/login.defs, you can still use /nonexisting as a home directory for system users (i.e. with UID in the range 201-999), e.g. when running useradd with the --system flag. This is because pwck does not check if directories exist for UID's in the system range. In fact, in my CentOS install the user for the cockpit service has home directory set as /nonexisting by default.
    – ofurkusi
    Jan 2 at 13:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.