-
Notifications
You must be signed in to change notification settings - Fork 84
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
"Operation not permitted" in Singularity containers #232
Comments
edit - sorry, I missed you used manually compiled versions also. @bedroge - Fedora has the latest Also, what is the host you are using? I wonder if that is having an impact here. I'm on Fedora 32 on the host too.
|
This is on an Ubuntu 20.04.1 (edit: kernel version 5.4.0-42-generic) host with Singularity 3.6.1, but I think I also tried this in a CentOS VM a few days ago, and had the same issues. I just tried it with a Fedora container, but unfortunately that does not work either:
The
Really weird... |
I just tried it on one of our cluster nodes, which has CentOS 7.8.2003 (kernel 3.10.0-1127.13.1.el7.x86_64) and Singularity 3.5.3-1.1.el7, but then I get even weirder behavior:
|
I'm seeing the same issues like @bedroge is seeing, with:
I can do the same with the minimal Fedora container that @dctrud was using:
Maybe it's related to using |
Since we still don't have a proper solution for this, besides using the old version 0.4.1, I was looking into this issue again today. I'm using a basic CentOS 7 image (in the following examples as sandbox, but the issue also occurs with regular sif images), and compiled fuse-overlayfs manually. The following shows what happens when I run a failing
Just for completeness, this is with the old version that does work:
So, for some reason, I can create a directory This can also be reproduced by doing the operations:
And, to make it even weirder: when I restart the container, leaving the
Don't know if this information helps in any way, but I really hope someone can find out what's causing this issue... |
The issue can be reproduced in the following way:
For me this results in:
|
FYI I cannot reproduce this on CentOS7 with singularity 3.6.4; instead, singularity prints a message during startup (in runFuseDrivers() according to -d) of
I can however reproduce it on CentOS8 with singularity 3.6.4, both with and without the --user option to run it unprivileged. Even better, I am able to reproduce it without singularity, by using my simple program to do fuse3 premounting instead. To compile the program on CentOS8, do the following steps:
Then do all of Bob's setup above except running singularity, and do these commands instead:
To unmount do This works for me on CentOS8, but just like with singularity, if I do the fuse-premount on CentOS7 and then try to do |
I'm seeing possibly related problems .. my development environment is Ubuntu 18.04 running in systemd-nspawn .. I've just upgraded the host environment to 20.04 and now I'm seeing operation not permitted errors. Stracing overlayfs:
syscall 0x1b5 is Might explain the failures in singularity if it similarly does syscall filtering? (I'm not familiar with it.) Not sure it explains @DrDaveD's results outside of a container manager though. |
singularity doesn't do syscall filtering by default. It can with |
I've tested this with some newer versions last year (don't remember which ones, but I guess 1.4.0, 1.5.0, and/or 1.6), but those didn't solve the issue. However, today I tried version 1.8, and that one does seem to solve the |
Just to add to this confusion more: On my home machine, running Debian 10 (Buster), using Singularity version
For what it is worth, on Rocky I get:
On Debian I get:
Right now I got the feeling there is something we are missing and depending on where Happy to provide more information. |
Looks like Bob was a tad bit too optimistic here, we had to revert back to fuse-overlayfs 0.3 (see EESSI/filesystem-layer#114), since we were still having trouble with version 1.8 in the end... :( |
This has become a bigger problem for apptainer (the new name for singularity) now while running in non-setuid mode because it causes the |
More info:
edit:
|
We tripped over this issue as well. Our installation environment is very similar to EESSI but we use Apptainer (1.1.8) as the runtime. The commit history made me suspicious and a quick bisect confirmed that this issue was introduced with 2666df2 |
@sven-hansen Could you please also submit an apptainer issue with a reproducer? I have fuse-overlayfs-1.11 on my el8 VM but haven't run across this, I don't think. As mentioned above, apptainer always uses the |
I'm trying to make use of fuse-overlayfs inside a Singularity container (based on CentOS 7) by using its new
--fusemount
option. Ideally I want to use this to make a writable overlay on top of a read-only CVMFS mount, but basically I'm just trying to do something like this:With recent version of fuse-overlayfs this seems to work partly: I can do some operations, like making new files, but some stuff does not work. For instance, making directories with
mkdir -p
(and sometimes even just cd'ing to the merged mountpoint) usually results in anOperation not permitted
, e.g.:Today I more or less accidentally found out that with a Debian 10 container everything does work fine. The default version in the Debian repo is quite old though, it installs fuse-overlayfs 0.3. Testing a bit more with various manually compiled versions, I found out that for both CentOS and Debian containers everything seems to work fine with versions up to and including 0.4.1, but with version 0.5 and newer I consistently get these errors.
Do you have any idea what could cause these
Operation not permitted
errors?The text was updated successfully, but these errors were encountered: