Hi,
Recently we tried to migrate orthanc from 1.7.4 to 1.9.4 and we encountered an issue when we tried to retrieve data.
One of our requirement is to keep existing data.
The stack trace we received is the following:
Caused by: feign.FeignException$InternalServerError: [500 Internal Server Error] during [GET] to [http://develop_pacs:8042/instances/e64902d9-a94b3bcd-1c915e40-23b26ed8-705d3f0f/simplified-tags] [OrthancFeignClient#getDicomFromOrthanc(String)]: [{ 150 “Details” : “The path does not point to a regular file: /var/lib/orthanc/db/d2/1d/d21ddd23-4afd-4c25-9c67-c7e1cd067a82”, 151 “HttpError” : “Internal Server Error”, 152 “HttpStatus” : 500, 153 "Messa… (471 bytes)]
We use the openFeign client to make http calls.
Do you know how we can solve this issue?
Kind regards,
Tarek Elmeskine
Hello,
The error is the following:
“The path does not point to a regular file: /var/lib/orthanc/db/d2/1d/d21ddd23-4afd-4c25-9c67-c7e1cd067a82”
=> You should have a look at why “/var/lib/orthanc/” is not correctly mapped. You don’t provide enough information about your environment for someone else to give additional advice.
Sébastien-
Hi Sébastien,
We presently use a docker with postgres and we use the jodogne/orthanc-plugin:1.7.4.
The issue occurs when we change the docker orthanc without changing anything in the volume mapping in order to keep the existing data.
The volumes mapped are the following:
- /var/log/orthanc/
- /var/lib/orthanc/db/
- /usr/share/orthanc/scripts
- /etc/orthanc/orthanc.json
Those volumes are correctly mapped since the issue occurs with the old data and not the new data inserted in the new orthanc version.
We tried to migrate from 1.7.4 to 1.8.2 as well as from 1.7.4 to 1.9.4 and we got the same issue.
Thank you for your help.
Kind regards,
TE
Hello,
I cannot provide any further advice if you don’t provide a full minimal working example for us to reproduce your issue independently of your setup:
https://book.orthanc-server.com/users/support.html#discussing-a-minimal-working-example
Sébastien-
You might want to check selinux labels (https://docs.docker.com/storage/bind-mounts/#configure-the-selinux-label) and use the ‘:Z’ option. That could explain that the file is inaccessible although correctly mapped.