After upgrading to DK 8.6 no images can be opened in my collection

Thu Feb 26 19:46:42 GMT 2026

Let me try to explain.

When adding a collection, digiKam creates a .dtrash folder and stores a 
digikam.uuid file in it. This file contains a random UUID string.

This UUID is used to identify the collection in the future. For local 
collections, there's a fallback to the partition UUID, but this has proven 
insecure under macOS, as current major macOS updates change the partition 
UUID. Under Windows, purchased removable drives pose a problem because 
identical models are assigned the same partition UUID by default.

Let's stick with the network drive example. If this UUID file isn't found, the 
collection is initially "offline." This can happen if the .dtrash folder is 
deleted externally, for example.

What does the Update button do? If no digikam.uuid exists, one is created and 
added to the database, and the collection is brought back online.

If a digiKam.uuid exists, it is read and written to the database, and the 
collection is back online.

After a change is made to the collection, a short scan of the albums is 
performed.

If you are running digiKam instances on different operating systems, you must 
attach the different mount paths to the existing network collection. Additional 
paths can be added to a network collection. Adding separate network 
collections will duplicate or triple the number of albums and images in the 
database.

Maik

Am Donnerstag, 26. Februar 2026, 13:42:57 Mitteleuropäische Normalzeit schrieb 
Thomas:
> Hi Maik,
> 
> Thanks!
> This seemed to do the trick!
> 
> That leads me to the following questions:
> 
> 0: What is  DK actually doing when I click this button and initiate this
> operation? It seems to require siginifanct amount of work. But the I/O
> throughput on the network between the NAS and the client does not seem
> to be too heavy. Rather it seems to be a lot of small operations. So I
> do not think it is re-reading all the photos. Is it just reading the
> metadata (e.g. what files are present, when were they changed, what
> size, etc.) and comparing to the database/inserting to the database?
> 
> 
> 1: Why does this happen? - that DK sometimes "forgets" about big chunks
> of my collection and thus stops being able to see files/folders in it?
> This has happened multiple times now. Am I doing something wrong outside
> of DK that triggers this issue?
> 
> 
> 2: This operation takes a /long/ time on a big collection. On my
> specific collection it has taken several days in which I must have the
> Mac up and running with DK doing this huge indexing operation. This
> means that I can effectively not use DK for those days, and worse: I
> cannot take my laptop anywhere, because I must leave it on the network
> during this whole time... Would it be possible to pause/resume this
> somehow across DK process start/stop?
> 
> 
> 3: I have a hunch that this might be relating to how macOS mounts SMB
> shares. Would it be possible to have DK talk to the SMB host directly
> rather than having the OS mount the files and have DK treat them as
> "local"ish files? I know some other application that does this where
> they talk directly to a given smb:// url that is not mounted on the OS.
> Would that be feasible - and would it even help solve this issue?
> 
> 
> 4: As a follow up to #0: IFF DK is merely indexing all the files and
> reading their metadata and then comparing with the local SQLite
> database, I think it might be possible to speed this up significantly by
> using a producer-consumer approach is done like this:
> 
>   * First, in one thread (producer thread): traverse through the
>     collection root (e.g. something similar to "find /path/to/collection
>     -ls") stream all metadata discovered to the consumer thread.
>   * Second, in a different thread (consumer-thread): consume all the
>     metadata in the buffer and query the SQLite db based on the incoming
>     metadata, process thumbnails, etc..
> 
> 
> I suspect what is happening is that DK is traversing through the
> collection, and when it spots a file, it processes is (query db, process
> thumbnails, etc); then it continues the traversing, and so on. IFF this
> is the case, it means that it will spend /a lot/ of time waiting for I/O.
> 
> 
> I just checked my NAS. It is able to do a full "find -ls" on my photo
> collection in the order of a few minutes. That is a /lot/ less than
> several days.
> 
> Now, I may be completely (or perhaps only somewhat) off in my analysis.
> 
> I would love to learn.
> 
> 
> BR
> 
> Thomas
> 
> On 2026-02-22 20.38, Maik Qualmann wrote:
> > Go to the digiKam settings under Collections. Next to the relevant network
> > collection, you'll find a tool button (a round icon). Complete all dialog
> > boxes, ensuring the path is correct. This will update the UUID for the
> > collection in the database.
> > 
> > Maik
> > 
> > Am Sonntag, 22. Februar 2026, 20:19:46 Mitteleuropäische Normalzeit
> > schrieb
> > 
> > Thomas:
> >> Hello Emre,
> >> 
> >> 
> >> Unfortunately, I have not been able to find a solution.
> >> 
> >> In fact, I have to now use a Windows machine in order to use DK.
> >> 
> >> I have even tried installing various "nightly builds" og Digikam 9.0 but
> >> alas, it does not work.
> >> 
> >> I think our setups are very similar:
> >>    * DK installed on macOS.
> >>    * Photo collection hosted on SMB/NAS.
> >> 
> >> Please let me know if you manage to sort this out. Please describe your
> >> problem in detail on thedigikam-users at kde.org mailing list (CC).
> >> Someone more experienced than me will hopefully help you out.
> >> 
> >> 
> >> 
> >> BR
> >> 
> >> Thomas
> >> 
> >> On 22/02/2026 20.14, Emre Ayhan wrote:
> >>> Hello Thomas,
> >>> 
> >>> I had a Problem with Digikam on my MacBook and came by your E-Mail
> >>> inside of the Digikam Mailing Archive, where you talked about the same
> >>> Problem with Digikam on your MacBook. Specifically it was about the
> >>> Digikam 8.6 upgrade and not being able to work with images which are
> >>> stored on Network Drives / NAS Storage (which is attached as a Volume
> >>> on MacBook) inside of Digikam.
> >>> 
> >>> If it's not a problem for you, I wanted to ask you if you could help
> >>> me out with my Digikam problem.
> >>> 
> >>> 
> >>> I came across the same Problem with my MacBook + Digikam and wanted to
> >>> ask you, what exactly made the Problem go away for you? I connected my
> >>> MacBook to the NAS via smb and the NAS Storage gets attached in the
> >>> Volumes directory. I gave Digikam full disk management rights in the
> >>> system settings and I also tried to run it via the terminal with logs
> >>> enabled, but I still did not get it to work, meaning that I cannot
> >>> open or copy the images inside of Digikam (which are stored on my
> >>> NAS). Do you have any other ideas or steps which I could use or try to
> >>> get my Digikam "working" again?
> >>> 
> >>> Thanks a lot
> >>> Emre Ayhan