nixos/image/repart: btrfs filesystems have wrong file permissions
Nobody has claimed this yet.
- Dominant language
- Nix
- Stars
- 26.2k
- Forks
- 20.1k
- PR merge metrics
- PR metrics pending
Description
Nixpkgs version
- Unstable (25.11)
Describe the bug
This is #361903 again: images with btrfs filesystems have wrong file permissions. The previous fix (#378579) was incomplete/didn't really work.
Steps to reproduce
- Build image through
image.repartwithbtrfsas filesystem
nix build --expr '((builtins.getFlake "github:nixos/nixpkgs?rev=01f116e4df6a15f4ccdffb1bcd41096869fb385c").lib.nixosSystem {
system = "x86_64-linux";
modules = [
({ pkgs
, modulesPath
, ...
}:
{
imports = [ "${modulesPath}/image/repart.nix" ];
image.repart = {
name = "bug-repro";
partitions."rootfs" = {
storePaths = [ pkgs.hello ];
repartConfig = {
Format = "btrfs";
Minimize = "guess";
Type = "root";
};
};
};
})
];
}).config.system.build.image'
- Inspect image (e.g. with
systemd-dissectorguestfish): files/directories in/nix/storeare writable
Expected behaviour
Files should have correct permissions (e.g. non-writable in /nix/store)
Screenshots
No response
Relevant log output
Additional context
mkfs.btrfs uses nftw to traverse the rootdir and fakeroot doesn't fake the stats passed to nftw callbacks.
Two potential fixes:
- Use
pseudo(not packaged) instead offakeroot, which has support fornftw - Use a patched
mkfs.btrfs: calllstatin thenftwcallback.fakerootwill intercept thelstatcall:diff --git a/mkfs/rootdir.c b/mkfs/rootdir.c index 7bdd6245..e940ef73 100644 --- a/mkfs/rootdir.c +++ b/mkfs/rootdir.c @@ -1631,7 +1631,7 @@ out: return ret; } -static int ftw_add_inode(const char *full_path, const struct stat *st, +static int ftw_add_inode(const char *full_path, const struct stat *ftw_st, int typeflag, struct FTW *ftwbuf) { struct btrfs_fs_info *fs_info = g_trans->fs_info; @@ -1639,9 +1639,16 @@ static int ftw_add_inode(const char *full_path, const struct stat *st, struct btrfs_inode_item inode_item = { 0 }; struct inode_entry *parent; struct rootdir_subvol *rds; - const bool have_hard_links = (!S_ISDIR(st->st_mode) && st->st_nlink > 1); + const bool have_hard_links = (!S_ISDIR(ftw_st->st_mode) && ftw_st->st_nlink > 1); u64 ino; int ret; + struct stat statbuf; + const struct stat *st = &statbuf; + + if (lstat(full_path, &statbuf) < 0) { + error("lstat() returned error for path %s", full_path); + statbuf = *ftw_st; + } /* The rootdir itself. */ if (unlikely(ftwbuf->level == 0)) {
System metadata
$ nix-shell -p nix-info --run "nix-info -m"
- system: `"x86_64-linux"`
- host os: `Linux 6.16.9, NixOS, 25.11 (Xantusia), 25.11.20251002.7df7ff7`
- multi-user?: `yes`
- sandbox: `yes`
- version: `nix-env (Nix) 2.28.5`
- nixpkgs: `/nix/store/9v6qa656sq3xc58vkxslqy646p0ajj61-source`
Notify maintainers
@nikstur
@WilliButz
Note for maintainers: Please tag this issue in your pull request description. (i.e. Resolves #ISSUE.)
I assert that this issue is relevant for Nixpkgs
- I assert that this is a bug and not a support request.
- I assert that this is not a duplicate of an existing issue.
- I assert that I have read the NixOS Code of Conduct and agree to abide by it.
Is this issue important to you?
Add a 👍 reaction to issues you find important.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue points to image/repart.nix, fakeroot, and the mkfs.btrfs source file mkfs/rootdir.c. Reproduce the supplied image build first, then inspect the resulting image with systemd-dissect or guestfish and trace how nftw statistics enter the filesystem creation step. Done means /nix/store files and directories have the expected non-writable permissions, with the chosen fix covered by a reproducible check.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, linux, nixos
- Domain
- build-system, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100