Cannot use one of the lower directories as mount target

[HiPhish]

As a user of fuse-overlayfs I would like to use one of the lower directories as the mount target. This allows me to trick applications which search one hard-coded directory into searching multiple directories. A lot of games are programmed such that the user is expected to drop extra data files (e.g. mods) into one common directory; removing one mod is near impossible, especially if one mod overwrites files from another. A layered file system allows me to keep mods separate while tricking the application into thinking that they have all been mushed together.

To replicate the issue create two directories a and b. Then mount a layered file system:

fuse-overlayfs -o lowerdir=a:b -o upperdir=whatever -o workdir=anything a

Don't actually try this, it will run into what feels like some sort of infinite loop. Unmounting a is impossible, FUSE will claim that the resource is busy. The only way I found to get rid of the mount was to reboot the machine.

In this example a represents the expected directory and b the custom one whose contents are to be spliced into a. a might contain some files of its own, so it is important to be included in the list. A workaround is to first rename a to _a or something else, then create a new directory a and mount everything as -o lower=_a:b a.

I don't know if this is a real bug or a limitation of FUSE.

[giuseppe]

does it get unstuck if you kill the fuse-overlayfs process?

The use case you have described is not supported since the lower dirs are supposed to be immutable (the same limitation exists for native overlay) otherwise the behavior is undefined.

[HiPhish]

I think you misunderstood, I did not mean for the lower directories to be mutated while the file system is mounted. The idea is to add mods (either manually or through a script) to a list, then when the game is started all the different directories are stacked into a file system that is mounteded for the duration of the game. Once the game process terminates the file system is unmounted again so the user can add or remove mods again. The game does not write to the file system, these files are read-only to the game.

does it get unstuck if you kill the fuse-overlayfs process?

Sort of, but now when I try ls a I get an error:

ls: cannot open directory 'a': Transport endpoint is not connected

[giuseppe]

Sort of, but now when I try ls a I get an error:

ls: cannot open directory 'a': Transport endpoint is not connected

you'd need to do an unmount there as well. fusermount - u a

I think you misunderstood, I did not mean for the lower directories to be mutated while the file system is mounted. The idea is to add mods (either manually or through a script) to a list, then when the game is started all the different directories are stacked into a file system that is mounteded for the duration of the game. Once the game process terminates the file system is unmounted again so the user can add or remove mods again. The game does not write to the file system, these files are read-only to the game.

I thought you wanted to use one of the lower layers as the target for mount. Unless the mount is going to be read-only that causes the lower layer to also be mutated.

I think it will be difficult anyway to support this scenario. There are cases where we cannot use *at syscalls, so we need to use the full path for file operations. So if you use a lower layer as the mount target, fuse-overlayfs itself will end up requesting files that are on the fuse-overlayfs mount itself.

[rapiz1]

I think the in-kernel overlayfs support this use case. And this pattern actually happens a lot within containerd. I suppose this is one of the main limitations of fuse and fuse-overlay?

[HiPhish]

you'd need to do an unmount there as well. fusermount - u a

Yes, that gets the directories unstuck. So my understanding is that this cannot be done with fuse-overlay, but only through regular FUSE with root access. Right?

[giuseppe]

no, the suggestion I gave was to correctly unmount the FUSE file system

[HiPhish]

I can only unmount (fusermount - u a) after killing the fuse-overlayfs process. If I try ls a, then ls gets stuck; I have to kill the shell, kill fuse-overlayfs and then unmount a. This gets the machine in a working state again, so that's fine.

The question is, can my original use-case be supported in fuse-overlayfs? If not then we can close this issue.

[LHLaurini]

The same issue seems to happen if you use a parent of the lowerdir as a target.

I believe this should be fixable by using mount namespaces, but that may require using two processes.

[Yato202010]

hi, it look like it's related to this issue #364 i tried and the behavior specified inside this issue is still the same . post 1.6 ( 1.6 not included ) have this issue as far as i tested . ( i tested with lower layer on multiple filesystem. i tried on a btrfs, a ext4 and a fat32 partition with the same behavior ) 1.6 and lower don't seem to have this issue ...

edits: with the 1.10 release it seems to be fixed