Add --overlay-opt option to pass extra overlayfs mount options - #784
Open
dam9000 wants to merge 1 commit into
Open
Add --overlay-opt option to pass extra overlayfs mount options#784dam9000 wants to merge 1 commit into
dam9000 wants to merge 1 commit into
Conversation
Add a new --overlay-opt option that passes additional mount options
to the kernel's overlayfs for the next --overlay, --tmp-overlay or
--ro-overlay mount. For example:
bwrap --ro-bind / / --overlay-src /opt \
--overlay-opt index=off,xino=off --tmp-overlay /opt true
This silences the overlayfs warnings seen with unprivileged bwrap,
which runs without CAP_DAC_READ_SEARCH in the initial user namespace,
so the kernel's file handle check fails for the upper and lower dirs:
overlayfs: upper fs does not support file handles, falling back to index=off.
overlayfs: fs on... does not support file handles, falling back to xino=off.
The "does not support file handles" wording is misleading: the
check is capability-based, so the warnings appear even on
filesystems with file handle support (and not when running as
root). index=off,xino=off skips the check.
--overlay-opt may be given before or after the --overlay-src
arguments, and may be repeated; the values are joined with a
comma. The value is passed unvalidated to the kernel.
The overlay mount failure messages now print the mount op's dest
instead of (null), which the last --overlay-src op has.
Test coverage: option before and after --overlay-src, repeated option,
dangling --overlay-opt and unconsumed --overlay-src.
Signed-off-by: Damjan 9000 <damjan.9000@gmail.com>
dam9000
force-pushed
the
pr-overlay-opt
branch
from
September 5, 2026 22:03
0b8e6e8 to
eb96463
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add a new --overlay-opt option that passes additional mount options to the kernel's overlayfs for the next --overlay, --tmp-overlay or --ro-overlay mount. For example:
This silences the overlayfs warnings seen with unprivileged bwrap, which runs without CAP_DAC_READ_SEARCH in the initial user namespace, so the kernel's file handle check fails for the upper and lower dirs:
The "does not support file handles" wording is misleading: the check is capability-based, so the warnings appear even on filesystems with file handle support (and not when running as root). index=off,xino=off skips the check.
--overlay-opt may be given before or after the --overlay-src arguments, and may be repeated; the values are joined with a comma. The value is passed unvalidated to the kernel.
The overlay mount failure messages now print the mount op's dest instead of (null), which the last --overlay-src op has.
Test coverage: option before and after --overlay-src, repeated option, dangling --overlay-opt and unconsumed --overlay-src.
NOTE: the value is passed unvalidated to the kernel (which will reject invalid values). Values duplicating bwrap's own upperdir / workdir / lowerdir / userxattr are not rejected; the kernel's last-wins parser means a resolvable user value overrides bwrap's. Let me know if you would want parse-time checks for these.
Resolves #783