Translation(s): Deutsch - English - Español - Français - Italiano
chroot is an utility that changes which folder is considered the root of the filesystem hierarchy by its child processes, so that it is impossible for them to access the parent folder of the new root, even though it physically exists on the disk.
Contents
Common use-cases
chroot utility is intended mostly for an occasional, ad-hoc usage.
If you regularly switch to some chroot-ed environment and even more, if you have multiple such, then consider using Schroot, that automates some tasks and does not require root privileges for a regular usage.
- Fast switching to another environment (distro, version, flavor, package mix) for the purposes of testing, building, debugging etc.
- Repairing a broken system by connecting its primary drive as an external drive (for example using an USB enclosure) to some working system and performing operations from within the system being repaired,
Historically chroot was also used to increase the security of network services running on a given machine: if an attacker managed to trick a service to an arbitrary code execution, he would still not have access to the whole filesystem of the machine (he would remain in a so called chroot jail). This however does not prevent the attacker from using the machine's network interfaces to further penetrate the internal network and furthermore on Linux and some other UNIXes escaping a chroot jail is relatively easy. As a result, for security-related purposes chroot was replaced by virtual machines and containers.
Basic setup and usage
Unless explicitly stated otherwise, all commands in the below subsections require root privileges.
Create or provide a file hierarchy of a Linux system
In the subsequent sections, ${chrootFolder} will refer to the root folder of a file hierarchy created or provided as described below.
- In case of switching to externally connected drives, it boils down to mounting them at a target folder of your choice.
In case you want to create a fresh Debian image, you can use utilities such as mmdebstrap, for example:
mmdebstrap --architectures=amd64,i386 --skip=output/dev,output/mknod --variant=buildd trixie "${chrootFolder}" http://deb.debian.org/debian
Mount virtual filesystems
As of 2026 these are procfs, sysfs, udev and their "children" of which there are too many and which also tend to die off or spawn way too often. Fortunately, mount has --rbind option that allows to bind an already mounted filesystem together with all its children to an additional target folder. Of course systemd decided to break some basic functionality, so you additionally need to use either --make-rslave or --make-rprivate flag to enforce the proper behavior (see mount_namespaces for details).
mount -t proc proc "${chrootFolder}/proc"
mount --rbind --make-rslave /sys "${chrootFolder}/sys"
mount --rbind --make-rslave /dev "${chrootFolder}/dev"
Copy DNS resolver config
cp /etc/resolv.conf "${chrootFolder}/etc/"
Perform a chroot switch
This usually boils down to
chroot "${chrootFolder}"...which will start an interactive login shell of root user inside the chroot-ed environment, so that you can interactively perform whatever tasks you need.
For non-interactive tasks, you can instead provide an alternative command and its args:
chroot "${chrootFolder}" /root/myScriptToBeExecutedInChroot.sh myArg1 myArg2/root/myScriptToBeExecutedInChroot.sh is a path inside the chroot-ed hierarchy.
Cleanup
After the chroot process exits, you need to unbind / umount all the virtual filesystems bound / mounted previously. Fortunately umount also has --recursive / -R flag to help with this:
umount -R "${chrootFolder}/dev"
umount -R "${chrootFolder}/sys"
umount -R "${chrootFolder}/proc"If ${chrootFolder} is a mount point of an external drive and you want to umount it also, you can replace all the above commands with the below single one:
umount -R "${chrootFolder}"
Additional notes and scenarios
Running X11 GUI apps
Running X11 GUI apps from within a chroot-ed environment and displaying them on host's X11 server works using standard mechanisms: just export the value of DISPLAY env var from the host in the chroot and make sure the host X server will allow connections (for example using xhost utility).
Running Systemd services
Systemd services will generally refuse to run in a chroot-ed environment. Use systemd-nspawn instead of chroot if you need to run Systemd services.
Modifying boot data of an external system
If you want to modify the boot data of another system whose drive you connected to the current one (this includes for example running update-grub, update-initramfs, installing a new kernel etc), you need to mount its /boot hierarchy. This may include the following:
/boot itself is often a separate partition, most commonly on systems using some disk encryption scheme.
On UEFI systems (which includes most modern x86 hardware), there will be a partition mounted at /boot/efi.
It is usually most convenient to mount these filesystems right after performing a chroot switch.
After performing the 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:
# /boot was on /dev/nvme0n1p2 during installation UUID=bc87fd6f-1dcf-4553-b39f-1cd16f0b3279 /boot ext4 defaults 0 2 # /boot/efi was on /dev/nvme0n1p1 during installation UUID=238A-8525 /boot/efi vfat umask=0077 0 1
If /etc/fstab entries use UUIDs as in the example above (which is the default on most modern distros), all you need to do is to point mount to their corresponding mount-points:
mount /boot mount /boot/efi
On some older systems, instead of UUIDs, device nodes may be used in /etc/fstab, like for example /dev/sdaX etc. In such case you need to figure out what device node currently corresponds to a given filesystem. Most commonly, it will be another partition on the same physical drive as the root filesystem of that external system.
After you are done with your chroot work, these filesystems may be umount-ed either from within the chroot or after exiting.