Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failure to replace a file that is non-writable in lower dir #377

Open
ydirson opened this issue Oct 17, 2022 · 2 comments
Open

Failure to replace a file that is non-writable in lower dir #377

ydirson opened this issue Oct 17, 2022 · 2 comments

Comments

@ydirson
Copy link

ydirson commented Oct 17, 2022

Context: trying to remaster an ISO by just fuse-mounting and modifying the overlay to generate a new ISO, without doing useless file copies. fuseiso gives me a filesystem where all files appear as readonly (and even owned by root).

There should be no reason to be unable to replace such a file in an overlay, but something seems to just prevent it:

$ mkdir lower upper work merged
$ touch lower/foo lower/bar
$ chmod -w lower/bar 
$ fuse-overlayfs -o lowerdir=lower,upperdir=upper,workdir=work merged/
$ mv merged/foo merged/foo0
$ mv merged/bar merged/bar0
mv: cannot move 'merged/bar' to 'merged/bar0': Permission denied
$ rm merged/bar 
rm: remove write-protected regular empty file 'merged/bar'? y
rm: cannot remove 'merged/bar': Permission denied
$ echo "new contents" > merged/bar 
bash: merged/bar: Permission denied

This can be worked around by adding updated files manually in upper dir, but it kinda defeats the purpose in the general case :)

@winnscode
Copy link

can't reproduce in my enviroment

$ fuse-overlayfs --version
fuse-overlayfs: version 1.10
FUSE library version 3.13.0
using FUSE kernel interface version 7.38
fusermount3 version: 3.13.0

@MartinLoeper
Copy link

Just noticed the same in the case where I tried to mount an overlayfs from user space onto the nix store in NixOS which is read-only by default.

As a workaround, I run the filesystem as root. I wonder why this is necessary in the current implementation. Definitely unexpected behaviour imo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants