Image is not writable

[hugues-talbot]

Running the jupyter image in writable mode seems to be forbidden:

vagrant@vagrant:~/singularity-web/nginx-jupyter$ sudo singularity run --writable jupyter.img
ERROR : Unable to open squashfs image in read-write mode: Read-only file system
ABORT : Retval = 255

[vsoch]

hey @hugues-talbot ! This image tutorial was done way before we even had squashfs images :) What you would want to do is to build with writable, like:

sudo singularity build --writable jupyter.simg Singularity

Let me know if that works for you and I can update the docs.

[vsoch]

Here is what I would try:
https://github.com/vsoch/singularity-web/pull/2/files

[hugues-talbot]

Hello Vanessa, Thanks for the quick reply. I had found the --writable flag on my own by reading the fine manual, but I now have another issue: 1- With a normal user, singularity complains that /run/user is not writable (which it isn't). It should be trying to access /run/user/1000, which is writable. 2- With root, jupyter complains that it shouldn't be run as root, and stops. I have tried several singularity scripts trying to setup a jupyter server, and they all fail in more or less same way. It could be a problem related to Ubuntu under virtualbox. Vagrant probably adds another layer of complexity.

…

On 2 January 2018 at 18:41, Vanessa Sochat ***@***.***> wrote: hey @hugues-talbot <https://github.com/hugues-talbot> ! This image tutorial was done way before we even had squashfs images :) What you would want to do is to build with writable, like: sudo singularity build --writable jupyter.simg Singularity Let me know if that works for you and I can update the docs. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABfDUBOQWRpsrWlz72Snv8yFomQRSf-6ks5tGmpZgaJpZM4RQySd> .

[vsoch]

hey @hugues-talbot ! I'm not sure about the /run/user vs /run/user/1000 - this might be something that you want to post on the singularity repository to get support.

For running as root, at least in this PR jupyter/notebook#1115 it looks like they added a command argument to allow for it. Try adding that.

If you want an actual server, then I would try defining a %startscript in the recipe, and then starting jupyter as a server there. Then you would do something like:

singularity instance.start container.simg jupyter
singularity instance.list

Give those things a try, let me know if you have any luck! Likely we should update these scripts to suggest using the instance from the getgo, since it's probably more appropriate.

[hugues-talbot]

Hello Vanessa, thanks gain. Yes there is exists an option for running the jupyter server as root but clearly we should avoid this. I'll see if someone has posted a solution for the /run/user problem.

…

On 3 January 2018 at 00:05, Vanessa Sochat ***@***.***> wrote: hey @hugues-talbot <https://github.com/hugues-talbot> ! I'm not sure about the /run/user vs /run/user/1000 - this might be something that you want to post on the singularity repository <https://github.com/singularityware/singularity> to get support. For running as root, at least in this PR jupyter/notebook#1115 <jupyter/notebook#1115> it looks like they added a command argument to allow for it. Try adding that. If you want an actual server, then I would try defining a %startscript in the recipe, and then starting jupyter as a server there. Then you would do something like: singularity instance.start container.simg jupyter singularity instance.list Give those things a try, let me know if you have any luck! Likely we should update these scripts to suggest using the instance from the getgo, since it's probably more appropriate. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABfDUKCKvG3jkZsnRyZbBVE3lEbuBjJYks5tGrYcgaJpZM4RQySd> .