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
Failed invoking the NEWUSER namespace runtime: Invalid argument #415
Comments
RedHat's implementation of user namespaces is very misleading.... While the kernel reports to support it, and the user space appears to be present, it is considered by Red Hat to be a "technology preview" and thus can only be enabled via a kernel boot argument (and even then, I'm not sure how functional it truly is). To get proper support on the system, you will need to ask your system administrator to install Singularity to the system as root so it can leverage a set UID code path which does not require the user namespace. Hope that helps! |
Ah, thank you for your help! |
My pleasure. I closed the ticket, but if you have any additional questions feel free to reopen it, create another or join our Slack or Google Group. Thanks! |
Worked for me too - FWIW I simply Thanks @gmkurtzer. |
I'm having the same problem on my university's HPC cluster even though the Admin installed Singularity 2.3.1 as root. I'm accessing Singularity via modules.
Here's some system info in case it's helpful:
If anyone has any other ideas let me know. I'd like to get this working on my university's HPC cluster if at all possible. |
@deepdawg, try running singularity with the -vvv option to get debug information on what it is doing. Also make sure that allow setuid = yes in /etc/singularity/singularity.conf (which is the default). |
@DrDaveD I am having similar problems to @deepdawg on my university HPC cluster (also accessed using lmod). I do believe that singularity was installed as root but I got the following debug output:
|
@stillill did you figure out the issue? |
im still having the same issues. singularity was install to root level system paths, though my users are still getting namespace errors $ uname -r $ singularity -vvv shell hello-world.simg |
|
The follows works for
|
Ok, this is really confusing, why does this work? $ sudo /usr/local/bin/singularity create container-centos7-test.img Singularity.container-centos7-test.img> |
Im sorry, I don't understand what you're trying to say. |
@mforde84 It could be helpful https://youtu.be/29NLgM9fnh4?t=437 |
I'm not clear how this is relevant to my question. I'm being told that I can only run containers with suid due to my kernel headers, yet I'm still able to generate a container and run it as an unprivileged user. Some clarification on why this works, yet other containers don't would be helpful. That or how I can generate containers with different kernel versions to support later versions of glibc would be helpful. |
@mforde84 Assuming you're still running on el6, if you are successfully invoking a container as an unprivileged user, you must now be using a singularity with setuid enabled. The setuid bit is not on the singularity executable itself, it is on a helper executable ending with "-suid" in /usr/local/libexec/singularity/bin. -vvv should tell you whether it is using the NON-SUID workflow or not; the previous one you posted said it was. |
Yep, VERBOSE: Checking for sexec-suid at /usr/local/libexec/singularity/sexec-suid Is there a way I can force this behavior for dockers I pull or build from someone elses repo/tags? Just for functionality sake? For instance, the hello world container (from above) is running from non-suid, can I throw a flag to the command forcing the suid path? Or can I completely disable user namespace execution with a compile / configure option? |
The image file run should make no difference to that, as far as I know. Are you sure you didn't change something? Try switching back and forth between the images with the same singularity installation. If you're still seeing sexec-suid you must have an old version. For a while it has been called action-suid. I'm quite sure that all versions that use sexec have security vulnerabilities. Please upgrade. |
Yea, I'm running 2.2.1 I believe. I can upgrade. Still testing to make sure this works as intended. So just a clarification, should configuration and the initial make be performed by root user? e.g, sudo su - Thats the only real differences I can see across my test cases. Maybe version difference as well. The installation that allows set uid was compiled as follows: su - nonrootuser |
Yes the second one is the right way to do it. Also ./autogetn.sh If you're using el6 I advise getting it from EPEL. I support the rpm there. 2.6.0 is in epel-testing and will be in epel next week. |
Great. Thanks. One additional question, and I can generate another ticket if you prefer. But one thing I'm running into issues with other peoples containers is a mount permission error: eg., If I understand correctly, it's, by default, trying to mount to loop block device which a read only fs. Do you have suggestions on how to mount to a shared path with read/write/exec mount flags, say within a lmod sourced build directory? |
Please create a new issue with all the details on how to reproduce. What you've given isn't sufficient for me to think of anything helpful. |
Hi, I am running into the same error when running on my local cluster.
The administrator compiled singularity from source using the following commands (he didn't want to pull it EPEL and singularity 3.0 has too many dependencies)
only changing the configure paths. These commands should work or are there some configure flags missing? What needs to be done to get things working? |
The key verbose message is "Running NON-SUID program workflow". Does /fusion/usc/opt/singularity/libexec/singularity/bin/action-suid exist, and does it have setuid root permissions? If so maybe /fusion doesn't allow executing setuid binaries. |
The directory where singularity is installed has permissions So what is the fix? Its it just a matter of changing the permissions of the files in |
Something messed with the ownership of the files, and that probably cleared the setuid bit. Yes the *suid files in that directory need to be owned by root and chmod u+s. |
Thanks that fixed it. Also for future readers the singularity.conf file also needs to owned by root. |
I came out the same problem, how to enable user namespaces unser el7.
|
Can you move your comment to a new issue and link to this one since it's over two years old and closed? Additionally, can you include the output of:
Thanks! |
For the record, el7.6 supports user namespaces without being a technology preview. It just needs to be enabled, for example with
|
I'm trying to test out Singularity on our cluster - I am not an administrator of the cluster, and I don't have root.
I created a few
tar
images on my laptop (Mac OSX, via vagrant), and sftp'ed them over to the cluster.On one of the cluster nodes, I compiled and installed singularity with:
So far so good. However, when I try to run the image, I get the error mentioned in the title:
Running it with
--debug
results in the following output:I've tried a variety of settings in
~/etc/singularity/singularity.conf
based on http://singularity.lbl.gov/docs-config, but I haven't hit upon a config that works. I started with the default config, of course.I believe that the kernel does support user namespaces, but I could be wrong. Here's some info in case it's useful:
The text was updated successfully, but these errors were encountered: