Translation(s): Deutsch - English - Español - Français - Italiano
chroot is a utility that changes which folder is considered the root of the filesystem hierarchy. Processes started with chroot cannot access the directories outside the new root
Contents
History
Nowadays chroot is mostly used for ad-hoc usage. See CategoryVirtualization for more modern approaches to virtualisation
Originally, chroot was used as a security measure: an attacker that managed to compromise a service that was started using chroot would not be able to access to the rest of the filesystem. Older guides will sometimes call refer to a service started using chroot as running in a chroot jail. Unfortunately, escaping the "jail" is relatively easy: if you want to secure a service, or run a different operating system, you will want to use something more modern like a container or virtual machine (see CategoryVirtualization).
However, chroot is still useful for testing or debugging.
Basic setup and usage
Create a chroot
In the following sections, ${chroot} is a directory, such as /var/tmp/chroot that will be used as the "new" root. It will need to contain various libraries and common directories. For example a program that expects to open the standard C library, will usually be looking for a path like /usr/lib/x86_64-linux-gnu/libc.so): when run using chroot, this means it will try and open ${chroot}/usr/lib/x86_64-linux-gnu/libc.so). The best way to ensure everything exists is to create a whole Debian installation under chroot using mmdebstrap (which can be run as non-root):
$ mkdir "$chroot"
$ mmdebstrap --mode=unshare --skip=output/mknod --variant=buildd stable "${chroot}"You can now run programs inside the chroot with, for example
# chroot "$chroot" bash
For non-interactive tasks, you can instead provide a command and arguments:
# chroot "${chroot}" /root/myScriptToBeExecutedInChroot.sh Arg1 Arg2where /root/myScriptToBeExecutedInChroot.sh is a path inside the chroot-ed directory (so it is actually found at $chroot/root/myScriptToBeExecutedInChroot.sh on the host).
Mounting virtual filesystems in a chroot
More complex programs need to access filesystems such as proc and sysfs, devtmpfs, which the chroot command does not set up. You can ensure these exist in the chroot in a number of ways: however, you should also consider using a more modern virtualisation approach such as nspawn, which will set these up for you.
From outside the chroot you can run something like:
# mount -t proc proc "${chroot}/proc"
# mount --rbind --make-rslave /sys "${chroot}/sys"
# mount --rbind --make-rslave /dev "${chroot}/dev"See mount and mount_namespaces for information about the --rbind option.
A limitation of chroot is that the binfmt_misc filesystem, which is usually mounted at /proc/sys/fs/binfmt_misc, cannot be mounted inside a chroot.
Copy the DNS resolver config
$ cp /etc/resolv.conf "${chroot}/etc/"
Cleanup
After the chroot process exits, you need to umount any the virtual filesystems added to the chroot:
# umount -R "${chroot}/dev"
# umount -R "${chroot}/sys"
# umount -R "${chroot}/proc"If ${chroot} is actually the mount point of an external drive, such as a USB disk, and you want to also umount the whole drive, you can replace all of the above with:
# umount -R "${chroot}"
Running graphical apps
Running graphical programs from within a chroot-ed environment and displaying them using the host's X11 server sometimes works using standard mechanisms: you will need to set the $DISPLAY environment variable inside the chroot and make sure the host's X server allows connections (for example using the xhost utility).
Systemd services
systemd services cannot be started in a chroot: use systemd-nspawn instead.
Foreign architectures
If qemu-user-binfmt is installed, it is possible to chroot to a filesystem for any foreign arch it supports. However, you will probably want to use Qemu instead.
Example: Modifying /boot for another system
A common use of chroot is for fixing boot issues. For example, you might boot into a RescueLive system, and chroot into the root directory to run update-grub, update-initramfs or reinstall a kernel). Most of the files needed for the BootProcess live in the /boot directory, which is usually a separate partition (and for UEFI systems you may need to mount the ESP partitions at /boot/efi).
After performing a chroot switch, check which filesystem are present by running grep /boot /etc/fstab. Below is an example output from a system with both /boot and /boot/efi entries:
UUID=7a307683-255a-4bac-937f-95aa2af2ca17 /boot ext4 defaults 0 2 UUID=4D18-6163 /boot/efi vfat umask=0077 0 1
If /etc/fstab entries use UUIDs as in the example above (this is the default on most modern distros) or unique PARTLABELs or LABELs, then all you need to do is to mount the appropriate filesystems:
mount /boot mount /boot/efi
On some older systems, instead of UUIDs or labels, you may see device nodes such as /dev/sdaX. In such case you need to figure out what device node corresponds to a given filesystem. Usually it will be another partition on the same physical drive as the external system's root filesystem.
After you are done with your chroot work, these filesystems may be umount-ed either from within the chroot or after exiting it.