NeuroDesk/neurocommand

Fatal error if pwd is not mounted in the container

Opened this issue · 4 comments

I don't know if this is the right repo to discuss this issue but here is what I got. I used the neurodesk mricrogl container in the past just fine, and today I updated things by re-running the build.sh --cli command. Then, when I tested it I got this error when I launched mricrogl:

FATAL:   failed to set working directory: chdir /opt/neurodesk: no such file or directory

I thought it was due to re-running the build script and couldn't figure out what went wrong. In the end, I figured out it was because my current working directory (/opt/neurodesk) was on a network mount that isn't known in the container. When I did a simple cd ~ everything worked normally again. My question is, can something be done (codewise) to avoid such an error? Otherwise, it would perhaps be good to add this caveat to the docs...

And now that I'm here, I was wondering when exactly the python requirements are needed. I suppose they are needed when running bash build,sh --cli, but are they also need for running fetch_containers.sh name version date? I'm asking because if I run e.g. the build script outside my python venv I don't get any error message...

  1. that’s an interesting bug. Did you manually start the container using singularity or did you use the wrapper scripts? The current directory should be mounted into the container automatically. Which version of apptainer/singularity are you running? Can you reproduce the bug on play.neurodesk.org?

  2. python is only needed for the build.sh, not for fetch_containers.sh

I used the wrapper script, and we are running apptainer version 1.1.5. I tried changing working directory to another network drive (/project, where our data lives), but that worked just fine. The only thing I can think of (but I'm a scientist, I'm not part of our computer group) is that the troublesome directory /opt is already mounted automatically inside the container as /opt_host. But I don't see why that should be a problem... But I then again, I must say that I don't know why our IT guys are mounting our /opt as /opt_host inside the container, I don't really see the point of that

Could it be that there is a name collision? My pwd was /opt/neurodesk and then the wrapper wanted to mount that directory in the container, but in there /opt already exists?