Plenty of packaging tools insist a file must be owned by root, and fakeroot-sysv satisfies that check without ever making you root. It fakes file ownership and permissions for cooperating programs, so you finish with a tar archive whose recorded owner is root-like while your real account stays exactly as unprivileged as it started. The installed command here is fakeroot 1.33 from package version 1.33-1, and the local fakeroot(1) and fakeroot-sysv(1) pages describe the same interface.
Allow about fifteen minutes. You need a shell, fakeroot, and an ordinary writable directory. The examples do not need sudo. Do not run them in a directory containing valuable files, because the archive commands create and overwrite named outputs.
Start by confirming which command is available and which version you are about to use. This is an ordinary, read-only check:
$ command -v fakeroot-sysv
/usr/bin/fakeroot-sysv
$ fakeroot-sysv --version
fakeroot version 1.33
$ dpkg-query -W -f='${Package} ${Version}\n' fakeroot
fakeroot 1.33-1
The fakeroot name is an alias commonly used by packaging tools. Use fakeroot-sysv when you want the installed System V IPC implementation named explicitly. Check the version on another machine before relying on an option or a saved state file: upstream versions can differ from this installed package.
Checkpoint: if the version command fails, stop here and install the package through your normal system administration process. Do not copy the shared library path from another host.
Choose a directory you can safely discard, then create one input file. No elevated privileges are required:
$ WORK_DIR="$PWD/fakeroot-test"
$ mkdir -p "$WORK_DIR"
$ printf '%s\n' 'archive payload' > "$WORK_DIR/payload.txt"
$ stat -c '%u:%g %a %n' "$WORK_DIR/payload.txt"
1004:1004 644 /path/to/fakeroot-test/payload.txt
Your numeric user and group IDs will differ. The important point is that the file has your real ownership before fakeroot starts. Replace /path/to/fakeroot-test in expected output with your actual path.
Warning: the next command changes the metadata view used by commands inside one fakeroot environment and writes an archive. It does not change the real ownership of the input file, but it can overwrite an existing archive.tar in this directory. Choose the workspace carefully.
Run the metadata changes and tar in the same fakeroot process. The -- marks the end of fakeroot options; the shell command after it belongs to the child:
$ fakeroot-sysv -- sh -c 'chown 0:0 "$1"; chmod 0644 "$1"; tar --format=ustar -cf "$2" -C "$(dirname "$1")" "$(basename "$1")"' sh "$WORK_DIR/payload.txt" "$WORK_DIR/archive.tar"
The chown and chmod calls are intercepted by fakeroot. They make later metadata queries in this environment report user and group ID 0 and mode 0644. They do not give the shell permission to read protected files, write protected directories, or change real ownership.
Checkpoint: inspect the archive outside fakeroot. The tar listing reads the ownership recorded in the archive:
$ tar -tvf "$WORK_DIR/archive.tar"
-rw-r--r-- root/root 16 2026-09-23 14:48 payload.txt
The timestamp and spacing vary. Look for root/root, mode -rw-r--r--, and the expected file name. If the listing shows your normal user instead, the archive command probably ran outside the fakeroot process or the metadata-changing command failed.
Now inspect the input with an ordinary command, outside fakeroot:
$ stat -c '%u:%g %a %n' "$WORK_DIR/payload.txt"
1004:1004 644 /path/to/fakeroot-test/payload.txt
The IDs should match the values from step 2. This is the central safety check. Fakeroot simulates the results of wrapped file-manipulation calls; it is not a privilege escalation tool and it is not a replacement for root when a real filesystem operation requires root.
If you need to remove this test state, verify the target first and then delete only the directory you created:
$ test "$WORK_DIR" = "$PWD/fakeroot-test" && rm -r -- "$WORK_DIR"
This undo command is destructive. Do not adapt it to a broad path, a variable you have not inspected, or a directory containing other work.
For a Debian package build, fakeroot is normally used around the packaging stage, where file ownership and modes must be recorded in the package. A typical command is:
$ dpkg-buildpackage -rfakeroot
Run the project's documented build command first and keep configuration and compilation outside fakeroot where possible. The manpage warns that configure-like probes can be confused when the system appears to behave differently. The command above may also create files in the parent directory, so read the package build documentation and check the output paths before running it.
Do not use fakeroot to test whether you can access a protected resource. A program may see a fake owner or mode through wrapped library calls while the kernel still denies the underlying operation. It also does not make network, device, mount, capability, or service-management operations safe for an unprivileged account.
The -s SAVE_FILE option saves fakeroot's metadata state, and -i LOAD_FILE loads state saved by an earlier run. This is useful for specialised workflows, but the manpage warns that state can leak or behave oddly if files touched inside the fake environment are then handled outside it. Loading with -i does not automatically save on exit; use -s as well when that is intended.
For a one-shot archive, keep the whole metadata-sensitive operation in one invocation and omit both options. If you do use them, keep the touched tree and state file under controlled ownership, do not share the state file with another user, and verify the restored archive before distributing it.
chown, the archiver, and the files it reads all ran inside the same fakeroot command.open() and cannot infer every ownership event. Create or touch the file in the controlled workflow, then inspect the archive.