Engelszüngeln: Fixing "No sandbox user" the Right Way

I'm setting up an ancient machine – a Pentium M box with a meme 256 MB of RAM – with current Debian bullseye, and I'm impressed that that still works: this machine is almost 20 years old. Hats off to the Debian folks.

But that's not really my story. Instead, this is about fixing what's behind the message:

No sandbox user '_apt' on the system, can not drop privileges

from apt. As you probably have just done, my first reaction was to feed that message to a search engine.

Quite a few pages were returned, and all I looked at suggested to simply create the user using one of the many ways a Debian box has for that. That is not totally unreasonable, but it does not really address the underlying cause, and hence I thought I should do better.

The immediately underlying cause is that for whatever deeper reason a maintainer script – shell scripts that Debian packages run after installing packages or before removing them – has not properly run; that is usually the place where packages create users and do similar housekeeping. Just creating the user may or may not be enough, depending on what else the maintainer script would have done.

Hence, the better way to fix things is to re-run the maintainer script, as that would either run the full routine or at least give an error message that lets you figure out the deeper cause of the problem. Dpkg runs the maintainer script(s) automatically when you re-install the package in question.

But what is that “package in question” that should have created the user? You could guess, and in this particular case your guess would quite likely be right, but a more generally applicable technique is to simply see what script should have created the user. That's not hard to do once you know that the maintainer scripts are kept (next to other package metadata) in /var/lib/dpkg/info/; so, with GNU grep's -r (recursive) option, you can run:

grep -lr "_apt" /var/lib/dpkg/info/

which gives the names of all files containing _apt in files below that directory. On my box, that is:

/var/lib/dpkg/info/python3-apt.md5sums
/var/lib/dpkg/info/libperl5.32:i386.symbols
/var/lib/dpkg/info/apt.postinst
/var/lib/dpkg/info/python3-apt.list

Ah-ha! The string is mentioned in the post-installation script of the apt package. Peeking inside this file, you see:

if [ "$1" = 'configure' ]; then
        # add unprivileged user for the apt methods
        adduser --force-badname --system --home /nonexistent  \
            --no-create-home --quiet _apt || true
fi

So: this really tries to create the user when the package is being configured, but it ignores any errors that may occur in the process (the || true). That explains why the system installation went fine and I got the warnings later (rather than a hard error during the installation).

Just re-configuring the apt package would therefore be enough to either fix things or at least see an error message. But really, unless it's a huge package I tend to save on brain cycles and just run apt reinstall, which in this particular case leads to the somewhat funky command line:

apt reinstall apt

For me, this fixed the problem – and I've not bothered to fathom why the user creation failed during initial system setup. If you've seen the same problem and still have a record of the installation, perhaps you could investigate and file a bug if necessary?

Letzte Ergänzungen