Hi,
Since vyos-build 201b8e0b1c (T9024: Podman 4.9.5 → 5.8.4, crun replaced by Debian Bookworm's runc 1.1.5), set container name <n> tmpfs <t> no longer works for containers running as a non-root user when the destination already exists in the image (typical:
/run/<service> owned by the service user). The tmpfs is mounted root:root 0755 and the service cannot create its pid file or control socket, so it fails to start. The same configuration worked on 2026.05.08-rolling.
Reproduction
FROM alpine
RUN mkdir -p /run/foo && chown 1000:1000 /run/foo
USER 1000:1000
podman run --rm --mount type=tmpfs,destination=/run/foo <image> sh -c 'stat -c "%U:%G %a" /run/foo; touch /run/foo/x'
| Stack | plain tmpfs | tmpfs-mode=1777 | U |
|---|---|---|---|
| Podman 4.9 + crun 1.8.1 (2026.05) | 1777, write OK | 1777 OK | OK |
| Podman 5.8.4 + runc 1.1.5 (2026.10) | root 755, write denied | ignored, denied | OK |
| Podman 5.8.4 + runc 1.5.2 | root 755, denied | 1777 OK | OK |
Same with --read-only. Podman alone behaves the same from 4.9 to 5.8. The difference comes from the OCI runtime.
Suggested fixes (either one)
- Add an option to container name <n> tmpfs <t>, e.g. chown (maps to the U mount option), and/or mode (tmpfs-mode). U is the only one that works with runc 1.1.5.
- Ship a newer runc, so that a mode option would be honoured.
Workaround
Use a volume on a host directory owned by the service user. Downside: pid files survive restarts.
Best,