EDIT Summary
For future users who encounter the problem the solution is,
docker run --platform linux/amd64 --rm -it -u 0 --entrypoint /bin/sh nvcr.io/nvidia/clara/clara-parabricks:4.0.1-1
I am unhappy with the practice of limiting Docker access via blocking standard runtime: there are statements of intent on SE as a strategy to attempt to restrict Docker access. Parabricks isn't an isolated incident of deploying this setup within bioinformatics. However, I checked their forum and there is no statement of intent that it's deliberate. Parabrick's copyrights are here. There would be issues if there was ever an official statement to this extent. They would likely argue it was for other reasons to automate stuff.
Original answer ...
I don't know parabricks, but I know Docker. What you are attempting is to run Docker from the outside ... I would get on the inside to view the error log. Whats happening is the error is not being passed outside the container. Getting on the inside requires
docker run --rm -it --name mydocker nvcr.io/nvidia/clara/clara-parabricks:4.0.1-1
This should give you access to the container. If it doesn't post back and I'll forward a different command that will. It's impossible to block access to a Docker container albeit some people try.
For simplicity is worth trying
docker run --rm -it --name mydocker clara-parabricks:4.0.1-1
Anyway, if you are using this approach you'll need,
docker cp *outside container* *insider container* nvcr.io/nvidia/clara/clara-parabricks:4.0.1-1 and vice versa
... this is an amazing command and allows you to move data in and out of the container. You've got to get the data on the inside of the docker and docker cp does that very well. I would then look to running the whole thing from the inside of the container. Thats exactly how I run Dockers, then I exit and return when it's done. There might be a bit of clean via this approach, I'm not sure --rm might take care of it.
You'll also be able to look at the programs and copy it out onto hard drive. This last bit may be not advisable - the whole point of Docker is to protect your system from their algorithms ... but you can definitely do it and if you get it paired up with NextFlow thats cool.
I don't particularly want to pull the Docker container because they're often huge and I've no interest in the algorithm albeit I've spotted its at nvcr.io/nvidia/clara/
Docker, to be honest it's lazy by the developers. Docker is - techie packaging. So it's good for reviewers and behind web firewalls. It's useful but like you've just experienced if it flops you're stuck. The one positive thing about Docker (apart from DevOps) is it's generally tolerated to package someone else's algorithm as part of a pipeline and let a third party 'pull it'. This is because they'll be a Dockerfile which can reconstruct the whole thing without copyright infringement. So if that first developer objects ... the Docker developer would just issue the Dockerfile. conda and stuff max out on that concept.
There's a weird error as the OP described below.
Right Docker uses by default a tag latest that does not work for parabricks. The tag must be 4.0.1-1. Could you retry the above code please?
Update For good measure try the following:
docker run --rm -it --name mystuff nvcr.io/nvidia/clara/clara-parabricks:4.0.1-1 --entrypoint /bin/bash
Might not be bash, thus
docker run --rm -it --name mystuff nvcr.io/nvidia/clara/clara-parabricks:4.0.1-1 --entrypoint /bin/sh
They shouldn't throw an error, but you might still find you are outside the container after running it. Lets see.
Update
The error looks okay, because a runtime error is exactly what would be expected if they are attempting to prevent access. Therefore please try:
docker run --platform linux/amd64 --rm -it -u 0 --entrypoint /bin/sh nvcr.io/nvidia/clara/clara-parabricks:4.0.1-1
This, or a variant of it, should work.
