-
Notifications
You must be signed in to change notification settings - Fork 19
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
use writable overlays? #39
Comments
Hi @stsp It's doable by putting fuse-overlayfs into the AppImage, and then invoking it from the Such functionality goes into the AppImage payload, not into the runtime. |
I actually thought your suggestion works... But it appears not. There is some problem, I think in fuse-overlayfs: it makes only the dir writable, but all existing files are still read-only, as strange as it may sound. I filled this ticket: containers/fuse-overlayfs#428 |
Sounds like a bug to me. |
Have you tried my reproducer? Does it reproduce for you as well? |
Sorry, can't try to reproduce right now. Can you reproduce this in a simple test case that does not involve AppImage? |
Ok, added a trivial test-case to the aforementioned ticket. |
And found the problem: the files are not writable if in the lowerdir they belong to another user. |
Hi, have the writable overlays been considered for appimages? I am trying to package the proprietary programs (a DOS programs actually) that are not educated enough to write to tmp dirs or alike. I think fuse has fuse-overlayfs, so such a feature is not going to be difficult to implement?
The text was updated successfully, but these errors were encountered: