resmgr: Downloaded models are not found

[Anphisa]

When I use resmgr to download a model, it isn't found. I don't see any error messages. Changing the data location for the models didn't help.

When using "ocrd resmgr list-installed", I also don't see the downloaded models. What am I doing wrong?
I use the Docker image under Ubuntu 20.04.

[mweidling]

Have you tried saving the models to a separate permanent directory on your host system and mounting it in your Docker container? I stumbled upon this, too, and following the steps proposed here did the job for me.

[Anphisa]

That solved it, thank you! I didn't find that part of the documentation.
For reference, I had to execute the commands relating to resmgr without specifying a docker user, so the commands have to be:

sudo docker run --volume $PWD/models:/usr/local/share/ocrd-resources ocrd/all:maximum ocrd resmgr download ocrd-calamari-recognize qurator-gt4histocr-1.0

sudo docker run --rm -u $(id -u) -v $PWD/data:/data -v $PWD/models:/usr/local/share/ocrd-resources -w /data -- ocrd/all:maximum ocrd process "calamari-recognize -I OCR-D-SEG-LINE-RESEG-DEWARP -O OCR-D-OCR -P checkpoint_dir qurator-gt4histocr-1.0"

Executing from the parent directory of both /data and /models.

[mweidling]

Glad to hear it helped and thanks for closing this issue right away!

[bertsky]

For reference, I had to execute the commands relating to resmgr without specifying a docker user

Oh, good point. The guide is indeed inaccurate here. Your solution of using root for the resmgr calls but then your host user for the subsequent data processing is a good workaround.

But that also means your $PWD/models will now be owned by your host's root. So this is not just a bug in our documentation, but we must find a better solution. (Another problem when running resmgr as unprivileged user without mounting /data is that you run into another permission problem right away, because no /data/ocrd.log can be created...)

@kba we should probably move this to ocrd_all and reopen.

[bertsky]

Another point is that ocrd_all does declare XDG_DATA_HOME=/usr/local/share, but XDG_CONFIG_HOME is unset, so it defaults to $HOME/.config which yields

PermissionError: [Errno 13] Permission denied: '/.config/ocrd'

when trying resmgr actions as unprivileged user.

[bertsky]

I believe the only sane way out of this maze is via userns-remap, i.e. by mapping the unprivileged host-side user to root user in the container.

[bertsky]

Ah, just saw this is a duplicate of OCR-D/ocrd_all#252 – which has -e HOME=/data as a workaround (but it requries you to mount /data already for the resmgr call). We still need to think about XDG_CONFIG_HOME and should consider userns-remap IMO.