"Path does not point to a regular file" when using only the postgresql index

Hi All,

I have been using Orthanc for a few months now mainly to take advantage of the REST api to run queries on a large set of DICOM Instances. Due to the large amount of images being uploaded to Orthanc, I have been using the postgresql plugin. I have also been using the “index-only” mode of orthanc by setting the “EnableStorage” of postgresql to “false”, and setting “StoreDicom” to “false”.
As I mentioned my main goal is to use orthanc to index a set of images and store only the DICOM tags and not the pixel data. The problem is that I have found that when I query orthanc for images using certain DICOM tags, it returns the “Path does not point to a regular file” error.

For example, this query works fine:

curl https://user:pass@myhost/tools/find -d ‘{ “Level” : “Series”, “Query” : { “Manufacturer” : “GE”} }’

However when I try to query for a tag like “SliceThickness” I get an error:

curl https://user:pass@myhost/tools/find -d ‘{ “Level” : “Series”, “Query” : { “Manufacturer” : “GE”, “SliceThickness” : “5”} }’
“Details” : “The path does not point to a regular file: /var/lib/orthanc/db/5e/b1/5eb11406-d6be-4075-a70b-2937714266ea”,
“HttpError” : “Internal Server Error”,
“HttpStatus” : 500,
“Message” : “The specified path does not point to a regular file”,
“Method” : “POST”,
“OrthancError” : “The specified path does not point to a regular file”,
“OrthancStatus” : 2006,
“Uri” : “/tools/find”

I don’t understand why Orthanc is looking in the /var/lib/orthanc directory as this directory does not even exist on the host, and orthanc should not be storing the DICOMs anyway. Are not all DICOM tags stored in the JSON summary that is generated during “index-only” mode?
All help and guidance is appreciated.


Hi Jasper,

I’ve just tried locally and it does work (osimis/orthanc-pro:19.3.4):

~$ curl http://localhost:8045/tools/find -d ‘{ “Level” : “Series”, “Query” : { “Manufacturer” : “Phi”, “SliceThickness” : “6.000000” } }’
[ “6d792dde-4045a82d-feed505a-a1908592-43b0d606” ]

Could you provide the problematic instance (anonymized)?

It doesn’t seem to be any particular instance that generates this error; as soon as there are instances present in the Database, a query for any of these tags results in an error. When you tried this on your local machine did you run Orthanc without Postgresql Storage enabled and “StoreDicom” set to false as well?

I have also been tinkering with the “StorageAccessOnFind” configuration option; what exactly does this configuration setting do when running orthanc in index-only mode? I have found that when I set this config setting to “Never”, Orthanc does not recognize some DICOM tags and returns an empty array “[ ]” on all queries that involve tags such as “BitsAllocated”, “HighBit”, and “SliceThickness”.

The option “StorageAccessOnFind” is documented in the default configuration file of Orthanc:

No issue in my side, even with StorageDicom and Postgresql storage enabled to false.


The “/var/lib/orthanc/db/” corresponds to the default configuration of the Debian/Ubuntu package that can be found in “/etc/orthanc”.

Please check out the following page of the Orthanc Book:

If “StoreDicom” is set to “false”, Orthanc will only store the JSON file, but not the DICOM file. So, the “StorageDirectory” (in your case, “/var/lib/orthanc/db/”) is still used to store JSON files.

You are probably mixing user permissions or using different configurations.


Thank you for the information,

I have a better understanding of how the index-only mode works now. Is it possible to store this JSON file in the postgresql database instead of the default storage directory? In other words if I enable storage in the postgres plugin, and keep “StoreDicom” as “false”, will no pixel data be stored in the database?

Yes, it should work. Just give a try…

Thanks all for the help so far.

I have deployed a configuration of orthanc that enables both the storage and the Index of the postgresql plugin, but sets the “StoreDicom” configuration option to “false”. It looks like the postgresql plugin does not respond to this setting, since the pixel data is still stored in the database, and the images can be previewed using the web viewer. The logs of orthanc on startup also don’t say anything about the dicom images not being stored, as is the case when the default file system is used during “index-only” mode. Is it possible that the postgresql plugin is not paying attention to the “StoreDicom” configuration option?

Indeed, the “StoreDicom” option is only available in the built-in storage on the filesystem.

If this is an issue for you, you can hire services from our commercial partner Osimis to get this feature implemented in the PostgreSQL plugins as free and open-source code: