Singularity: Non-root installation method

[rtripath89]

Hi,

I was wondering if there is a method to install singularity to HPC, without root privileges.

If we need to give root permissions for some files after installation, is there a list of those files?

Thanks.

Ravi

[dtrudg]

@rtripath89 - the non-root installation method is basically the same as installing with root, but configure with the --without-suid option - it leaves you with an installation that doesn't use setuid, and lacks some functionality - most notably cannot run SIF images (only sandboxes).

./mconfig --without-suid --prefix=/home/dave/singularity-nonroot
make -C builddir
make -C builddir install

If you later need an install as root, which can use setuid, we recommend re-installing, not modifying permissions and config.

[pclemins]

I'm in the same boat as rtripath89... And have been working on this for a few weeks on and off. I have my sandbox built with version 3.4.2-1 locally:

singularity build --sandbox ubuntu16 docker://ubuntu:16.04

and compiled singularity 3.4.1-1 on the HPC exactly as specified above. I transferred my sandbox directory to the HPC, but when I try:

singularity shell ubuntu16/

I get...

ERROR : Failed to set effective UID to 0

and when I try:

singularity shell --userns ubuntu16/

I get...
WARNING: underlay of /etc/localtime required more than 50 (82) bind mounts
FATAL: shell /bin/sh doesn't exist in container

HPC is running SUSE Enterprise 12 SP4. The --without-suid compile seemed to work as I have no starter-suid in my libexec/singularity/bin/ directory, only a starter as I'd expect. I also tried setting allow setuid = no in my .conf, but again, no dice.

@rtripath89, You having better luck?

[rtripath89]

@pclemins : Not really.... I was able to get a non-root installation, by following steps mentioned by @dctrud , but without the ability to use sif images, and everything you pull down is pulled as a sif image, it's not really help, as I can't run any of the images pulled down.

[jmstover]

@rtripath89 ... When running this way, I thought it should use user namespace, and create a sandbox of a SIF image.

So... you can pull down a SIF image ... and it gets converted to a sandbox image, and ran that way.

[jmstover]

@pclemins

when I try:
singularity shell ubuntu16/
I get...
ERROR : Failed to set effective UID to 0

I know there was a logic bug in a version that would always check for UID 0, even when it shouldn't have. Don't remember what version that was though... @cclerget do you recall?

3.4.2 stands out to me, but I don't know if that's correct, or I just have that version stuck in my head for some reason. :/

[cclerget]

Yes @jmstover you're right, version before 3.4.2 didn't fallback correctly for unprivileged installation, @rtripath89 @pclemins you could give a try with 3.5.2 release: https://github.com/sylabs/singularity/releases/tag/v3.5.2.
@rtripath89 as @jmstover mentioned your system must support user namespaces. What's the distribution your are running Singularity ? Between unprivileged installation can use SIF image as Singularity extract container partition to a sandbox automatically so if you have errors with 3.5.2 release you should take a look at user namespaces on your system.

[pclemins]

@jmstover @cclerget You were both 100% correct. Did an unprivileged installation of 3.5.2 and now, singularity shell ubuntu16/ results in:

WARNING: underlay of /etc/localtime required more than 50 (82) bind mounts
FATAL: shell /bin/sh doesn't exist in container

So... First, I tackled the /bin/sh error. That was dumb user error. I was using Globus to transfer my sandbox and Globus ignores symlinks (/bin/sh -> dash) by default, which slipped my mind. So, I tarred the sandbox, transferred it and untarred it. Issue fixed with a sheepish grin.

Second, the underlay bind mount issue. I tried building a more minimal distribution: singularity build --sandbox minideb-wine/ docker:bitnami/minideb:jessie (it's annoying that I can't do a recipe w/o sudo), transferred it and... WOAH! Singularity on the HPC! Unfortunately, I couldn't do a shell --writable on the HPC because it didn't like mounting my pwd, so back to my local machine to tweak the sandbox to get my packages installed. But, it's late and Friday and time for a night cap and some sleep. More this weekend or Monday on my quest.

Thanks a ton for your help so far... making progress!

[pclemins]

Success! So, documenting some things here for posterity so others don't have to search unsuccessfully like I did for some details:

On the HPC:

• Download the latest singularity and setup the go compiler per website instructions:
  https://sylabs.io/guides/3.5/user-guide/quick_start.html#quick-installation-steps
• Compile as described with one exception... include the --without-suid and --prefix options as so:
  ./mconfig --without-suid --prefix=<some path you have write access to>/singularity-install
• make and make-install as described at the above website

On your local machine:

• You can use sudo singularity build to build from image or recipe (i.e. definition file), but you HAVE to build to a directory using --sandbox (non-suid singularity doesn't do .img files) like so:
  sudo singularity build --sandbox minideb/ docker:bitnami/minideb:stretch
• sudo tar czvf (z and v optional) the directory... tarring it instead of just rsync'ing or globus'ing or scp'ing the directory does 2 important things:
  1) insures symlinks, which are widely used in /lib directories and /bin directories, are preserved
  2) strips the root root ownership of files so that your non-suid install of singularity on the HPC doesn't have a fit. And, when you extract, you'll be the owner of files. As an example:
  sudo tar czvf minideb.tar.gz minideb/
• Transfer the tar.gz to the HPC by any means you wish.

On the HPC:

• Extract the tar...
  `tar xzvf minideb.tar.gz'
• Run singularity:
  `/bin/singularity shell minideb/

Notes:

• Configure the sandbox on your local machine... I had issues with singularity mounting directories on the HPC for --writable
• Use a minimal linux container. I started with Ubuntu 16.x (before they went minimal by default in 18.x+) and I got warnings about underlay's having too many mounts. You'll see I tried minideb for this example. Worked good...

[dtrudg]

Unprivileged installation is now documented in the updated guides.