chroot: Changing the Root Directory to Isolate an Environment

2026-06-06 Reading time: About 10 min Difficulty: Intermediate

What You'll Learn

• How chroot switches the root directory a process sees
• How to diagnose "the command won't run inside chroot" as a shared-library problem
• A reliable system-recovery workflow from a live USB or rescue mode
• Why chroot is not a security boundary and what to use instead

What Is chroot?

Conclusion: chroot changes the apparent root directory (/) for a process and its children to a directory you specify, so that process can no longer reach files outside the new root.

Normally every process resolves paths from the system-wide root /. When you run chroot /mnt/newroot, everything under that point becomes the new / for the affected process.

$ sudo chroot /mnt/newroot

From that moment, the chrooted shell's /etc/passwd actually points to /mnt/newroot/etc/passwd. Anything outside the new root (the host's real /home, for example) can no longer be named as a path. That is why chroot is described as "isolating an environment."

Why Use chroot?

Conclusion: The three main uses are system recovery, clean build/test environments, and confining a service. Reach for it when you want to run a command against a filesystem that is independent of the running one.

Typical use cases:

How Do You Run chroot?

Conclusion: The syntax is chroot NEWROOT [COMMAND]. Omit the command and it launches the user's shell ($SHELL or /bin/sh) interactively. Root privileges are required.

Basic syntax:

$ sudo chroot NEWROOT [COMMAND [ARG...]]

Without a command:

# Start an interactive shell inside the new root
$ sudo chroot /mnt/newroot

With an explicit command:

# Run /bin/ls inside the new root, then exit
$ sudo chroot /mnt/newroot /bin/ls -l /

What Does a chroot Environment Need?

Conclusion: Besides the command binary itself, the shared libraries (.so files) it depends on must exist inside the new root. Otherwise it fails with "No such file or directory."

This is the classic pitfall. Running chroot /mnt/newroot /bin/bash fails if /mnt/newroot/bin/bash is missing — and even when the binary is present, the shared libraries bash links against must also live inside the new root.

Find the dependencies with ldd:

$ ldd /bin/bash

        linux-vdso.so.1 (0x00007fff...)
        libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f...)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f...)
        /lib64/ld-linux-x86-64.so.2 (0x00007f...)

Copy each .so to the same path inside the new root and bash will run. A minimal jail built by hand:

$ NEWROOT=/mnt/jail
$ sudo mkdir -p $NEWROOT/{bin,lib,lib64}
$ sudo cp /bin/bash $NEWROOT/bin/
# Copy the .so files ldd reported into the matching directories
$ sudo cp /lib/x86_64-linux-gnu/{libtinfo.so.6,libc.so.6} $NEWROOT/lib/
$ sudo cp /lib64/ld-linux-x86-64.so.2 $NEWROOT/lib64/
$ sudo chroot $NEWROOT /bin/bash

Recovering a System with chroot

Conclusion: To repair an unbootable OS, mount its disk, bind-mount /dev, /proc, and /sys into it, then chroot. This lets you operate the installed OS almost as if it had booted normally.

Steps to enter the installed OS from a live USB or rescue mode, assuming /dev/sda1 is the root partition:

# 1. Mount the target root partition
$ sudo mount /dev/sda1 /mnt

# 2. Bring in the virtual filesystems via bind mounts
$ sudo mount --bind /dev  /mnt/dev
$ sudo mount --bind /proc /mnt/proc
$ sudo mount --bind /sys  /mnt/sys

# 3. chroot into the installed OS
$ sudo chroot /mnt

# 4. Now operate normally (e.g. reinstall GRUB)
# grub-install /dev/sda && update-grub

When finished, exit the chroot before unmounting. Getting the order wrong gives you target is busy.

# Exit the chroot first
# exit

$ sudo umount /mnt/sys /mnt/proc /mnt/dev
$ sudo umount /mnt

Is chroot a Security Boundary?

Conclusion: No. chroot only changes the filesystem view; a process with root privileges can escape it using well-known techniques. Use namespace-based containers for real isolation.

Treating chroot as a sandbox is dangerous. A process running as root inside a chroot can escape (a "chroot escape") with classic tricks such as a double chroot. This is a design limitation, not a bug.

What chroot does not isolate:

• The process table (ps sees outside processes, and you can kill them)
• Networking (the same network stack is shared)
• Users and privileges (root inside the chroot is the host's root)
• The kernel (shared)

Common Errors and Fixes

Conclusion: Most failures come down to missing shared libraries, missing bind mounts, or insufficient privileges. Read the error message to tell them apart.

chroot: failed to run command '/bin/bash': No such file or directory

If the bash binary exists but you still see this, the shared libraries (including the loader) are missing inside the new root in almost every case. Match the output of ldd /bin/bash into the new root (see the dependencies section).

$ ldd /bin/bash   # Run on the host to list the .so files you need

chroot: cannot change root directory to '/mnt': Operation not permitted

You lack root privileges — add sudo. The same error appears when CAP_SYS_CHROOT has been dropped, such as inside a container.

Lots of "command not found" after chroot

Either PATH doesn't match the new root's layout, or the needed commands aren't installed. A minimal root may not even contain ls. Lay down a complete userland with debootstrap or similar.

umount reports target is busy

You're trying to unmount before leaving the chroot shell. exit the chroot first, then unmount in the order /sys, /proc, /dev, /mnt.

# Enter
sudo mount /dev/sda1 /mnt
sudo mount --bind /dev  /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys  /mnt/sys
sudo chroot /mnt

# After your work, exit the chroot, then:
sudo umount /mnt/sys /mnt/proc /mnt/dev
sudo umount /mnt