/dev/null permission denied in chroot environment

Question

I have Xubuntu 18.04 in a chroot environment. I just dropped it in there from a VM I had of it.

Going into the chroot environment, if I try to run apt update I get this error:

/usr/bin/apt-key: 624: /usr/bin/apt-key: cannot create /dev/null: Permission denied

I have tried most of the solutions here: https://unix.stackexchange.com/questions/146633/bash-dev-null-permission-denied As well as this solution: https://superuser.com/a/814594 Neither worked. Same exact output.

Is there some way I can get this working? Thanks in advance.

Answer 1

I encountered this issue today.

I could resolve it by binding the host machine's /dev/ to chroot environment's /dev/.

# Run in host machine as root(sudo)
mount --bind /dev /path/to/chroot/environment/dev

Also in my case, I needed to bind 3 more file systems.

# Run in host machine as root(sudo)
mount --bind /dev/pts /path/to/chroot/environment/dev/pts
mount --bind /proc /path/to/chroot/environment/proc
mount --bind /sys /path/to/chroot/environment/sys

And then chroot into the environment:

chroot /path/to/chroot/environment

Answer 2

From man null:

   These devices are typically created by:

          mknod -m 666 /dev/null c 1 3
          mknod -m 666 /dev/zero c 1 5
          chown root:root /dev/null /dev/zero

These commands would have to be executed in the chroot environment.

Answer 3

I know this is old and you already found your answer, but another possibility (which I just faced) is that the drive was mounted with the nodev option, disabling any character devices such as /dev/null, even though they show up with the proper permission. Just issuing a mount -o remount,rw /dev/hdaN /mnt from outside the chroot fixed it.

Answer 4

Figured out the issue. It wasn't readable/writable by all users. Changed it so all users could read and write and it worked. Thanks anyways!

Answer 5

Instead of adding GPG keys for an apt repository inside a chroot with apt-key, you can also place them directly into the /etc/apt/trusted.gpg.d directory with a file extension of either .asc or .gpg according to this Debian bug I stumbled across.

In my case, I was trying to add an apt repository inside a chroot environment while building a base image for my containers.

For example:

wget -q "SOME_URL_HERE" -O- | run_in_chroot sh -c 'cat >/etc/apt/trusted.gpg.d/mykey.asc';

...where run_in_chroot runs a command inside a chroot:

run_in_chroot() {
    chroot "path/to/directory/to/chroot/into" "$@";
}