Flatpak build fails in flatpak-builder: bwrap can't create user namespace in unprivileged runner container #313

New issue

Open

opened 2026-06-27 00:52:27 +00:00 by james · 0 comments

james commented

2026-06-27 00:52:27 +00:00

Owner

Follow-up to #293/#294. With the Rust 1.85 bump (#294) the Tauri binary now compiles successfully on tag runs, but the Flatpak job then fails one step later in flatpak-builder. Confirmed on run 780.

Failing step + evidence

The carol Rust binary compiles (Finished release profile [optimized] target(s) in 3m 03s), then flatpak-builder dies on the module's first build-command:

Building module carol in .../build/flatpak/state/build/carol-1
Running: install -Dm755 carol -t /app/bin/
bwrap: Creating new namespace failed: Operation not permitted
Error: module carol: Child process exited with code 1
🏁  Job failed

Root cause

flatpak-builder runs every module build-command inside a bwrap sandbox, which must unshare() a new unprivileged user namespace. The job runs in container ghcr.io/catthehacker/ubuntu:js-24.04 on the self-hosted act_runner, and that container isn't permitted to create user namespaces → Operation not permitted. (The earlier non-fatal bwrap warning during the org.freedesktop.Platform.openh264 install is the same cause surfacing harmlessly.) The existing --disable-rofiles-fuse flag only addresses the FUSE overlay, not the userns requirement.

Fix (when we're ready to apply it)

Add options: --privileged to the job's container: block in .forgejo/workflows/release-flatpak.yml:

     container:
       image: ghcr.io/catthehacker/ubuntu:js-24.04
+      # flatpak-builder runs every module build-command inside a bwrap
+      # sandbox, which must unshare() an unprivileged user namespace.
+      # The default (unprivileged) runner container forbids that —
+      # "bwrap: Creating new namespace failed: Operation not permitted".
+      # --privileged grants the userns + seccomp/apparmor + /dev/fuse
+      # access bwrap needs. Requires the act_runner to permit privileged
+      # containers (see config.yaml [container].privileged / options).
+      options: --privileged

The minimal-cap variant (--security-opt seccomp=unconfined --security-opt apparmor=unconfined --device /dev/fuse) does not by itself re-enable unprivileged userns creation, so it generally still fails with the same error. flatpak-builder has no "disable sandbox" flag (only flatpak build does), and even a trivial install build-command runs through bwrap — so --privileged is the standard fix.

⚠️ Why this is held / not a YAML-only change

Security tradeoff. --privileged grants the release CI container broad host access — a deliberate posture change worth weighing for a tag-triggered release job.
Runner-side config required. container.options: --privileged is only honored if act_runner allows it. On the runner host's config.yaml:
```
container:
  privileged: true        # permit privileged job containers
  options: ""             # must not strip the job's options
```
…then restart act_runner. Also the host's Docker daemon must allow privileged containers and unprivileged userns (no kernel.unprivileged_userns_clone=0, no userns-remap). These are owner/runner-side actions the workflow change alone can't satisfy.

Remaining latent steps (unproven — past the bwrap wall)

The build has never progressed beyond this point, so each of these could be the next failure once userns works:

The rest of the carol module's install commands (desktop file, metainfo XML, 8 icon sizes) — files must exist next to the manifest.
appstream/metainfo validation (appstreamcli compose over tech.wynning.carol.metainfo.xml) — most likely next failure if the metainfo is malformed.
flatpak build-export and flatpak build-bundle.
Release-attach step polling forge.int.wynning.tech for the same-tag release page (untested timing assumption).

Verify

On the next v*.*.* tag run, the bwrap: Creating new namespace failed line should be gone and flatpak-builder should proceed through the remaining install commands → build-bundle → .flatpak attach.

Relates to #278, #293, #294, run 780.

Follow-up to #293/#294. With the Rust 1.85 bump (#294) the Tauri binary now compiles successfully on tag runs, but the Flatpak job then fails one step later in `flatpak-builder`. Confirmed on **run 780**. ## Failing step + evidence The `carol` Rust binary compiles (`Finished release profile [optimized] target(s) in 3m 03s`), then `flatpak-builder` dies on the module's **first** build-command: ``` Building module carol in .../build/flatpak/state/build/carol-1 Running: install -Dm755 carol -t /app/bin/ bwrap: Creating new namespace failed: Operation not permitted Error: module carol: Child process exited with code 1 🏁 Job failed ``` ## Root cause `flatpak-builder` runs every module `build-command` inside a `bwrap` sandbox, which must `unshare()` a new **unprivileged user namespace**. The job runs in container `ghcr.io/catthehacker/ubuntu:js-24.04` on the self-hosted act_runner, and that container isn't permitted to create user namespaces → `Operation not permitted`. (The earlier non-fatal `bwrap` warning during the `org.freedesktop.Platform.openh264` install is the same cause surfacing harmlessly.) The existing `--disable-rofiles-fuse` flag only addresses the FUSE overlay, not the userns requirement. ## Fix (when we're ready to apply it) Add `options: --privileged` to the job's `container:` block in `.forgejo/workflows/release-flatpak.yml`: ```diff container: image: ghcr.io/catthehacker/ubuntu:js-24.04 + # flatpak-builder runs every module build-command inside a bwrap + # sandbox, which must unshare() an unprivileged user namespace. + # The default (unprivileged) runner container forbids that — + # "bwrap: Creating new namespace failed: Operation not permitted". + # --privileged grants the userns + seccomp/apparmor + /dev/fuse + # access bwrap needs. Requires the act_runner to permit privileged + # containers (see config.yaml [container].privileged / options). + options: --privileged ``` The minimal-cap variant (`--security-opt seccomp=unconfined --security-opt apparmor=unconfined --device /dev/fuse`) does **not** by itself re-enable unprivileged userns creation, so it generally still fails with the same error. `flatpak-builder` has no "disable sandbox" flag (only `flatpak build` does), and even a trivial `install` build-command runs through bwrap — so `--privileged` is the standard fix. ## ⚠️ Why this is held / not a YAML-only change 1. **Security tradeoff.** `--privileged` grants the release CI container broad host access — a deliberate posture change worth weighing for a tag-triggered release job. 2. **Runner-side config required.** `container.options: --privileged` is only honored if **act_runner** allows it. On the runner host's `config.yaml`: ```yaml container: privileged: true # permit privileged job containers options: "" # must not strip the job's options ``` …then **restart act_runner**. Also the host's Docker daemon must allow privileged containers and unprivileged userns (no `kernel.unprivileged_userns_clone=0`, no userns-remap). These are owner/runner-side actions the workflow change alone can't satisfy. ## Remaining latent steps (unproven — past the bwrap wall) The build has never progressed beyond this point, so each of these could be the next failure once userns works: 1. The rest of the `carol` module's `install` commands (desktop file, metainfo XML, 8 icon sizes) — files must exist next to the manifest. 2. **appstream/metainfo validation** (`appstreamcli compose` over `tech.wynning.carol.metainfo.xml`) — most likely next failure if the metainfo is malformed. 3. `flatpak build-export` and `flatpak build-bundle`. 4. Release-attach step polling `forge.int.wynning.tech` for the same-tag release page (untested timing assumption). ## Verify On the next `v*.*.*` tag run, the `bwrap: Creating new namespace failed` line should be gone and `flatpak-builder` should proceed through the remaining `install` commands → `build-bundle` → `.flatpak` attach. Relates to #278, #293, #294, run 780.

james referenced this issue from a commit

2026-06-27 00:54:52 +00:00

ci(flatpak): disable release-tag trigger while the build is blocked

james referenced this issue

2026-06-27 00:55:01 +00:00

ci(flatpak): disable release-tag trigger while the build is blocked #315