pastilhasandClaude Opus 5 401dcb710c a blessed directory for container bind mounts
From a live-server report: a bind-mounted postgres:18-alpine crash-looped with
`mkdir: can't create directory '…/18/docker'` on a directory that already existed.

3bea46f stripped default ACLs from ~/.local/share/docker and I concluded the ACL problem
solved. It covered NAMED VOLUMES only. A bind source lives wherever the member put it, and
there the same collision returns by another route: the image's inner uid is 70, mapped
through the member's subuid range to 231141 — neither the service user nor the member, so
`other` — and the home carries default:other::--- from the file browser's ACLs. A named
volume passes with this bug present, which is exactly why the first fix looked complete.

~/.local/dockers is now provisioned as the documented place for compose bind mounts: mode
711, all ACLs removed. Two details that are the whole fix:

  711, not 700 — a container's inner uid is `other` and needs x to reach a bind source
  inside. No ACL can grant what the mode denies, and 700 blocks the path before any ACL is
  consulted. `r` stays off so nothing can list it, and the home above is still 700, so no
  other account can traverse this far anyway.

  setfacl -b, not -k — `-k` removes defaults but left mask::--- behind, so inherited named
  entries read as `user:pastilhas:rwx #effective:---`. An ACL that says one thing and means
  another is worse than none, and container storage wants ordinary mode bits.

Chosen over the alternatives: extending the strip cannot work when the member chooses the
path, and d:other::--x on the whole home loosens every directory forever to fix one local
case. Bounded deliberately — a bind mount from elsewhere in the home still hits the denial.
This is the place that works, not a promise about everywhere.

VERIFIED: the directory comes out `user::rwx group::--- other::--x` with no ACL and no
defaults, which is the design exactly.

NOT VERIFIED: a container actually starting from a bind mount in it. My host recycles uid
1001 across probe accounts and a stale /run/user/1001 — a systemd runtime mount that
survives rm — leaves the new account with no bus, so rootless Docker will not start here.
That is the deprovision/uid-reuse problem in the queue, hitting the test rig. The live
server is the place to confirm it: green is uid 1002 with no recycling, and the report that
prompted this came from there.

docs/per-user-linux-accounts.md line 337 predicted a milder version of this and said
"nothing does today". Corrected: something does, and the ACLs had removed the traverse bit
its 711 reasoning assumed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 20:54:39 +00:00
2026-02-16 19:34:35 +00:00
2026-02-16 19:34:35 +00:00
2026-02-16 19:34:35 +00:00
2026-02-22 03:35:26 +00:00
2026-02-16 19:34:35 +00:00
2026-02-16 19:34:35 +00:00
2026-08-11 15:15:09 +00:00
S
Description
No description provided
42 MiB
Languages
TypeScript 90.9%
Shell 4.7%
JavaScript 4.1%
CSS 0.2%
HTML 0.1%