binpash
Unshare fails on nested mounts
On a docker container, --privileged is required for unshare to work.
When running try, mount fails in the overlayfs.
❯ ./try echo hi
mount: /tmp/tmp.nFUDbAZ10u/temproot/bin: wrong fs type, bad option, bad superblock on overlay, missing codepage or helper program, or other error.
mount: /tmp/tmp.nFUDbAZ10u/temproot/boot: wrong fs type, bad option, bad superblock on overlay, missing codepage or helper program, or other error.
mount: /tmp/tmp.nFUDbAZ10u/temproot/etc: wrong fs type, bad option, bad superblock on overlay, missing codepage or helper program, or other error.
<snip>
unshare: failed to execute /bin/bash: No such file or directory
The solution in https://stackoverflow.com/questions/67198603/overlayfs-inside-docker-container Fixes the issue.
> mkdir /tmp/overlay
> mkdir /tmp/{low,merged}
> mount -t tmpfs tmpfs /tmp/overlay
> mkdir /tmp/overlay/{up,work}
> mount -t overlay overlay -o lowerdir=/tmp/low/,upperdir=/tmp/overlay/up/,workdir=/tmp/overlay/work/ /tmp/merged/
I am not too sure why we need to place it in tmpfs for it to work in docker. cc @mgree
I think it's a nesting issue: https://stackoverflow.com/questions/67198603/overlayfs-inside-docker-container#comment123545455_67208735.
That makes sense, should we work on support for running try in docker/overlayfs?
I don't think it's a huge priority---if you're running in those environments, you need try much less.
In a setup where we have a --bind(and possibly others) mount setup in a like /home, we get the following error when trying to mount it in overlayfs.
mount: /tmp/tmp.nFUDbAZ10u/temproot/home: wrong fs type, bad option, bad superblock on overlay, missing codepage or helper program, or other error.
And in dmesg, we see the following
[308798.929868] overlayfs: failed to set xattr on upper
[308798.929873] overlayfs: try mounting with 'userxattr' option
[308798.929883] overlayfs: failed to clone lowerpath
https://elixir.bootlin.com/linux/latest/source/fs/overlayfs/super.c#L1665
Reproducible on the following.
eric@try-test-lvm:~/try$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 50G 0 disk
└─sda1 8:1 0 50G 0 part
├─vg0-vg0--root 254:0 0 27.9G 0 lvm /
├─vg0-lv--home 254:1 0 9.3G 0 lvm /home
└─vg0-lv--homemnt 254:2 0 12.7G 0 lvm /home/eric/mnt
sr0 11:0 1 957M 0 rom
Mounting the directories via mergerfs to a tempdir, then mounting overlayfs with the tempdir as it's lowerdir seems to be able to fix this. This method also fixes #56.
A fix has been pushed to branch nested-mount.
Should we work to support nested mounts via mergerfs @mgree
Is there a reason a simpler, comes-with-default-Linux approach like unionfs wouldn't work? I'm wary of adding too many dependencies.
Is there a reason a simpler, comes-with-default-Linux approach like unionfs wouldn't work? I'm wary of adding too many dependencies.
Unionfs works, however on my debian setup it requires the installation of unionfs-fuse package.
cat /proc/filesystems | grep union Yields nothing on my Ubuntu and Debian machines
I agree we shouldn't add too many dependencies, perhaps we can make it a flag to enable/disable or use it only if merger/unionfs is installed.
Okay, fair enough. Let's see if we can use the same approach for both, and then we can detect (or have the user select) a union fs to use.
