Bug 504359

Summary:	Using digiKam across two machines causes "storage location not available" error after switching machines.
Product:	[Applications] digikam	Reporter:	kde
Component:	Database-Files	Assignee:	Digikam Developers <digikam-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	metzpinguin
Priority:	NOR
Version First Reported In:	8.6.0
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:	8.7.0
Sentry Crash Report:

Description kde 2025-05-16 21:16:02 UTC

**Setup:**
I am using DigiKam on two machines (a laptop and a desktop) that share a common Pictures folder. This folder is kept in sync both ways using Syncthing. My goal is to use DigiKam seamlessly across both machines depending on where I am (e.g., home vs. on the go). Here's how I've set it up:

* The DigiKam database is stored inside the Pictures folder.
* I use the default SQLite with WAL (Write-Ahead Logging) mode.
* DigiKam is configured to:

* Write metadata changes to image files.
* Watch for external changes.
* Use the same absolute path to the Pictures folder on both systems.

**Observed Behavior:**

* On Machine 1, everything works perfectly. Images, previews, face recognition, metadata, etc., all function as expected.
* I close DigiKam on Machine 1 and sync everything via Syncthing (all image files and the four main database files: digikam4.db, thumbnails-digikam.db, etc.).
* On Machine 2, I open DigiKam with the same configuration. It correctly loads the synced databases and recognizes the entire collection. Everything seems to work fine.
* I then close DigiKam on Machine 2, sync again via Syncthing, and try to open it on Machine 1.

This is where the problem starts:

* Although DigiKam launches and all previews are still visible, trying to open any image results in the message:
"The storage location of this image is currently not available."
* To fix this, I have to:

* Go into Settings > Configure DigiKam > Collections,
* Remove the Pictures folder path,
* Re-add the same path again.
* After doing this, everything works normally again. But this workaround needs to be repeated every time I switch machines.

**Question / Request:**

* Is this behavior expected when using SQLite in WAL mode across two synced environments?
* Is there a better way to set this up, or is this a bug in how DigiKam tracks mount paths or collection metadata?
* Could DigiKam be enhanced to better support multi-machine use with synced databases?
* Ideally, I'd like to avoid removing/re-adding the collection path every time I switch between systems.

Comment 1 Maik Qualmann 2025-05-17 05:49:05 UTC

Where are your images/database located, on a NAS or your desktop computer?

Why do you always have to sync? Are you working on a local copy first?

What collection type did you add your image path as?

I suspect you're overwriting the digikam.uuid file, which is located in the .dtrash folder in the root of the collection.

First of all, SQLite over the network is slow and shouldn't be used.

Normally, the collection is located on the network, e.g., on a NAS. This path is added as a network path on machine 1. Now, on machine 2, it is "appended" to the existing network path; different mount points are possible.

You can probably solve your problem with your approach by adding the collection paths as a network type in digiKam to prevent a new digiKam.uuid from always being created for different local hard drives.

https://docs.digikam.org/en/setup_application/collections_settings.html

Maik

Comment 2 kde 2025-05-17 07:35:20 UTC

Thanks for the helpful response. It works now.
Just to clarify my setup: both my images/pictures and the DigiKam database files are stored locally on each of the internal SSDs of my laptop and desktop. I'm not using any kind of NAS or shared network storage—just two local folders that I keep in sync with Syncthing. I know that’s not the most common setup, but for a few reasons, I’m sticking with it, which is why I opened this issue in the first place.

To answer your question about the collection type: I originally added the image path as a local collection on both machines. I also tried setting it up as a removable media collection, but that didn’t seem to help. I had come across the digikam.uuid file in .dtrash while troubleshooting and suspected it might be part of the problem, but wasn’t entirely sure how to deal with it. After your hint about that I now realized this is likely why DigiKam treats the same path as two separate collections—even though the folder structure and files are exactly the same.

Following your suggestion, I tried setting the folder up as a network collection on both systems, even though it's technically just a local path on each one. That seems to have done the trick—DigiKam no longer gets confused, and switching between machines now works smoothly.