Closed pditommaso closed 6 years ago
It should be noted that when using the docker hub the same command works as expected, eg.
singularity pull --name $PWD/name.img docker://debian:wheezy
This looks like an issue with the name, this works:
$ singularity pull shub://nextflow-io/rnatoy
+ singularity pull shub://nextflow-io/rnatoy
Progress |===================================| 100.0%
Done. Container is at: ./nextflow-io-rnatoy-master.img
this doesn't (using a path)
$ singularity pull --name $PWD/name.img shub://nextflow-io/rnatoy:master
+ singularity pull --name /home/v$ singularity pull shub://nextflow-io/rnatoy
+ singularity pull shub://nextflow-io/rnatoy
Progress |===================================| 100.0%
Done. Container is at: ./nextflow-io-rnatoy-master.img
anessa/Desktop/name.img shub://nextflow-io/rnatoy:master
Progress ||----------------------------------| 0.0% ERROR Error downloading https://www.googleapis.com/download/storage/v1/b/singularity-hub-regional/o/singularity-hub-regional%2Fgithub.com%2Fnextflow-io%2Frnatoy%2Fff90eda9453c0e85e18fb27357ba1ae4537fa1d9%2F377d6c373fa4e17f52663a41f980aaf4.img.gz?generation=1499454150065440&alt=media. Do you have permission to write to /home/vanessa/Desktop/home/vanessa/Desktop?
Remove the path variable but still ask for a name, it works ok again:
singularity pull --name name.img shub://nextflow-io/rnatoy:master
+ singularity pull --name name.img shub://nextflow-io/rnatoy:master
Progress |===================================| 100.0%
Done. Container is at: ./name.img
The intended use was to specify name, and then singularity_pullfolder as where to download it,eg:
SINGULARITY_PULLFOLDER=/tmp singularity pull --name name.img shub://nextflow-io/rnatoy:master
+ SINGULARITY_PULLFOLDER=/tmp
+ singularity pull --name name.img shub://nextflow-io/rnatoy:master
Progress |===================================| 100.0%
Done. Container is at: /tmp/name.img
But I agree that the example you provided should work too. Could you use one of the workarounds above while we have time to fix this?
Yes, I think I can live with that.
Want to laugh?!
SINGULARITY_PULLFOLDER
works only when using shub://
. Instead when pulling from docker://
is ignored 😃
Nice one !!
see https://github.com/singularityware/singularity/pull/855 !
/laughing on the outside, crying on the inside :sob:
Hi @vsoch - looks like this one was fixed. Ok to close?
Yes, indeedy! Closing.
I know this has been closed a long time but are singularity version 2.6.1 requests to any docker:// addresses now blocked with the error noted here? It was a convenient way to create writable containers...
singularity build --writable lolcow.sif docker://godlovedc/lolcow
Docker image path: index.docker.io/godlovedc/lolcow:latest
Cache folder set to /local/docker
[1/6] ||----------------------------------| 0.0% ERROR Error downloading https://index.docker.io/v2/godlovedc/lolcow/blobs/sha256:3b61febd4aefe982e0cb9c696d415137384d1a01052b50a85aae46439e15e49a. Do you have permission to write to /local/docker
I would say that Singularity 2.6.1 is so old it can't be supported anymore, but I'm not a developer here.
Version of Singularity:
2.3-dist
Expected behavior
It should pull a container image from the Singularity Hub and store in the specified path.
Actual behavior
When pulling an image from the singularity hub and an absolute path is specified as target image image the following error message is returned.
If the container is pulled from the docker hub, it works fine.
Steps to reproduce behavior