"Operation not permitted" when trying to open file for write

[stsp]

This may be related to #232 but I prepared a ready-to-use test-case, it is attached: fuse_test.AppImage.gz

After you gunzip it, you'll get the AppImage file called fuse_test.AppImage. All it does is mounts the read-only lower dir and the writable upper dir into the mount-point. Then it does test -r and test -w to check if the file is actually readable and writable. Unfortunately its not writable, in which case it prints the failure message and also prints mount | grep fuse that allows you to inspect the mount params. In fact, its not like the entire dir is not writable - it IS writable. You can create new files there. But the files that come from the lower dir, are themselves not writable for some unclear reason.

I also added the --debug option for you. With that option fuse-overlayfs is started with -d and you can see the logging. I also added the --keep option which just mounts the dirs, prints the mount point and exits without doing any checks and without unmounting. This may be needed if you want to work with the mount-point by hands.

I hope this test-case will help to narrow down the problem.

[stsp]

ovl_tst.tar.gz Here's the completely trivial test-case that doesn't even involve AppImage. Just a trivial script. It mounts the archive with archivemount and then adds a writable overlay. The very interesting thing is that the bug can be reproduced only with SOME archives. The one that is attached, triggers the bug. But if I try to create the similar archive by hands, then bug doesn't trigger... So the problem is probably much deeper than the one could expect.

[stsp]

Found the problem: fuse-overlayfs doesn't make the files writable if in the lowerdir they belong to another user.

[stsp]

In fact, the ownership is propagated from lowerdir to the mountpoint. Maybe fuse-overlayfs should set the ownership to the mount owner, and ignore the ownership in the lowerdir?

[probonopd]

I think what should be done is to do copy-on-write under the user running fuse-overlayfs while not caring about the user of the file in the lowerdir?

[stsp]

I think what should be done is to do copy-on-write under the user running fuse-overlayfs while not caring about the user of the file in the lowerdir?

I bet the write request doesn't even come to fuse-overlayfs in that case. Kernel's FUSE module has paranoid permission checks, and likely denies the request if the file has another owner. I think the only work-around is for fuse-overlayfs to change the owner explicitly.

[stsp]

Got things working with this hack:

diff --git a/main.c b/main.c
index b5753db..58836c8 100644
--- a/main.c
+++ b/main.c
@@ -971,8 +971,8 @@ rpl_stat (fuse_req_t req, struct ovl_node *node, int fd, con
st char *path, struc
   if (ret < 0)
     return ret;

-  st->st_uid = find_mapping (st->st_uid, data, true, true);
-  st->st_gid = find_mapping (st->st_gid, data, true, false);
+  st->st_uid = find_mapping (getuid(), data, true, true);
+  st->st_gid = find_mapping (getgid(), data, true, false);

   st->st_ino = node->tmp_ino;
   st->st_dev = node->tmp_dev;
@@ -3186,12 +3186,14 @@ copyup (struct ovl_data *lo, struct ovl_node *node)
   if (dfd < 0)
     goto exit;

+#if 0
   if (st.st_uid != lo->uid || st.st_gid != lo->gid || get_upper_layer (lo)->stat_override_mode != STAT_OVERRIDE_NONE)
     {
       ret = do_fchown (lo, dfd, st.st_uid, st.st_gid, mode);
       if (ret < 0)
         goto exit;
     }
+#endif

   buf = malloc (buf_size);
   if (buf == NULL)

[probonopd]

Would you be able to send a pull request?

[stsp]

This patch is definitely wrong, it can't be sent as a PR. I'll simply add the hacked-up fuse-overlayfs to my AppImage, and things are good.

[stsp]

Its not like I don't care about an upstream version, but fuse-overlayfs has quite a lot of uid mapping and overriding modes which I am not aware about. Maybe enabling some override mode already achieves the same thing, I've no idea. So I'll just take a short-cut and package the hacked-up version.

[probonopd]

It would be good if this could be fixed properly by the maintainer of this repo, so that it would be fixed for everyone. Thanks!