The command line I am using is

dpkg --force-not-root --root  /some/other/location -i the_package.deb

but I get an error

dpkg: could not open log '/var/log/dpkg.log': Permission denied

I would have expected the log to have been written to


With rpm you can generate an alternate database but I can't see how to do this with dpkg. To get to the above state I manually added (perhaps not the wisest approach) the following.

mkdir -p /some/other/location/var/lib/dpkg/updates
mkdir -p /some/other/location/var/lib/dpkg/triggers
mkdir -p /some/other/location/var/lib/dpkg/info
touch /some/other/location/var/lib/dpkg/status
touch /some/other/location/var/lib/dpkg/available

If I try to run as root, which I would prefer not to do in this case

sudo dpkg --force-not-root --root  /some/other/location -i the_package.deb

it gets further and installs the deb in my alternate location but then fails with

dpkg (subprocess): unable to execute installed post-installation script (/var/lib/dpkg/info/the_package.postinst): No such file or directory

but this file has been written by the dpkg command above to


My reasoning for not using the machines dpkg database is that this is an applications software install to a network drive that is available to a number of users. Perhaps just extracting the contents of the package and manually installing is the best approach. The particular software package does not have any external dependencies listed.

Debian 'dpkg' package management program version 1.18.2 (amd64)

1 Answer 1


Use --log=filename to change where you log.

If you are using --root=/foo you need to set up /foo as a valid root. E.g., sudo chroot /foo /bin/sh works.

The "No such file or directory" is indicating that the the_package.postinst script requires something that is not in the chroot (most likely /bin/sh and a boatload of other things). That is run from within the chroot so you don't see /foo in the path.

You could use --no-triggers to prevent the triggers from running. However you should now see what a hack this is becoming. dpkg is heavily biased toward thinking you want to run the package on the machine on which you are installing it and the root filesystem is at /.

"[J]ust extracting the contents of the package and manually installing it will be a better approach." Yes-- it looks like you are installing it on a file server that is not intended to run it.

Edit: Though this strictly solves your problem the "modern" method to distribute software is to use orchestration software (e.g., chef) to install the packages directly on the clients rather than sharing software via a fileserver. Disks are cheap.

  • Thanks. It looks like using dpkg is not the right approach for installing packaged software to a fileserver. Thanks for the tip about 'chef'.
    – user993269
    Mar 1, 2016 at 15:08
  • Thanks, that helped, but I must say that mentioning "chroot directory" is confusing. That is because you can't chroot as a non-root, but then the question is about doing dpkg installation as a non-root… I get you meant that the destination dir of the dpkg command should be a system that one could chroot into if they wanted so, but it's not obvious one the first read. I think it might help to be explicit with something like "The dpkg destination dir should be a system that one could chroot into if they wanted".
    – Hi-Angel
    Mar 30, 2021 at 14:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .