digikam can't find NFS which is actually mounted

[Maik Qualmann]

Is it possible that your NFS collection is not yet mounted when you start 
digiKam? But the path is writable and there is no file UUID. And since we have 
a UUID in the DB create a new one? Ok, this scenario is possible, but we can 
fix it. We can no longer do without the UUID file, since under macOS the 
partition UUID changes with every OS update. We use UUID file in order to 
recognize the collection.

If the NFS is not mounted, please check whether there is a .dtrash/
digikam.uuid file?

Maik

Am Montag, 29. Januar 2024, 21:50:14 CET schrieben Sie:
> Thanks Maik -- this is a mystery for me too. Nothing changed in the
> remote collection or the local box. I'm just closing digikam, turning
> off the computer, coming back again the next day turning the computer
> on, mounting the NFS share, and starting digikam. I'm not an expert in
> NFS, but is it possible that it changes UUID of the same filesystem
> under some conditions? If so, relying on UUID may not be reliable?
> 
> Perhaps there is a way to disable the UUID method if it causes trouble,
> and fall back to the old on directory name?
> 
> Diego
> 
> On 1/29/24 12:49, Maik Qualmann wrote:
> > OK, the old method doesn't work here because we found both a file UUID in
> > the database and in the collection.
> > So the question is, why aren't they the same? A collection cloned onto the
> > NAS or something similar?
> > 
> > Maik
> > 
> > Am Montag, 29. Januar 2024, 19:41:48 CET schrieben Sie:
> >> The saved file UUID c013b4e8... differs from the file UUID 37698a21...
> >> found in the collection. The question is, why? What did you do? The
> >> technology is new, but I have no idea how this can happen. In addition,
> >> the old method of detection of the collection would still apply in this
> >> case.
> >> 
> >> Maik
> >> 
> >> Am Montag, 29. Januar 2024, 19:28:41 CET schrieben Sie:
> >>> Thanks Maik. Here seems to be the relevant output (the share mounting
> >>> point is /mnt/compart_bebu_b/ and Pictures/ is the directory where the
> >>> pictures are):
> >>> 
> >>> digikam.database: Creating new Location  "/"  uuid
> >>> 
> >>>    "networkshareid:?mountpath=/mnt/compart_bebu_b/Pictures&fileuuid=c013
> >>>    b4e
> >>>    8-
> >>> 
> >>> f234-46 9a-901e-b3dc7f04a88d"
> >>> digikam.database: Found Location "/mnt/compart_bebu_b/Pictures" with
> >>> file uuid "37698a21..."
> >>> digikam.database: Location for "/mnt/compart_bebu_b/Pictures" is
> >>> available: false => case sensitivity: 2
> >>> 
> >>> I'm attaching the complete output just in case it adds more info.
> >>> 
> >>> Thanks,
> >>> 
> >>> Diego
> >>> 
> >>> On 1/29/24 12:05, Maik Qualmann wrote:
> >>>> If the collection is not recognized, create a log of the debug output
> >>>> of
> >>>> digiKam in the terminal as described here:
> >>>> 
> >>>> https://www.digikam.org/contribute/
> >>>> 
> >>>> At the moment one could only guess. For a network collection,
> >>>> digiKam-8.2.0
> >>>> and above uses two functions to recognize that the collection is
> >>>> mounted
> >>>> and that it is the correct one. On the one hand, the new file UUID (the
> >>>> file is in the .dtrash path), but as a fallback, the old method from
> >>>> the
> >>>> path and at least one folder/file must be present.
> >>>> 
> >>>> Maik
> >>>> 
> >>>> Am Montag, 29. Januar 2024, 17:20:11 CET schrieb Diego:
> >>>>> Hi -- somehow digikam seems to be losing its information about NFS
> >>>>> shares even though the NFS is successfully mounted on the system.
> >>>>> These
> >>>>> is all the evidence I have:
> >>>>> 
> >>>>> 1. When I double click on a picture I get a message "The storage
> >>>>> location of this image is currently not available".
> >>>>> 
> >>>>> 2. When I open digikam, it finishes searching for new items in 0 secs.
> >>>>> This is odd since it typically takes between 1 or 2 mins)
> >>>>> 
> >>>>> 3. When I go to settings -> configure digikam -> collections. I see my
> >>>>> network share, but the little "network symbol" next to it, is grayed
> >>>>> out.
> >>>>> 
> >>>>> 4. On the right pane, under the "Properties" tab, the Folder (under
> >>>>> "File Properties") starts with "???/" instead of the mounting point of
> >>>>> the NFS as it should.
> >>>>> 
> >>>>> 5. On a terminal, I can "df" or "mount" and see the filesystem there.
> >>>>> In
> >>>>> fact I can cd and open and pictures/movies with gwenview, mplayer,
> >>>>> vlc,
> >>>>> etc. So, the NFS share is definitely mounted and accessible (I can
> >>>>> also
> >>>>> write on it).
> >>>>> 
> >>>>> 6. If in settings/configure digikam/collection I click on the circular
> >>>>> arrows next to the NFS path which says "updates the path of the
> >>>>> collection" and select exactly the same directory as before, it starts
> >>>>> rescaning everything (and I think rebuiliding the database, all of
> >>>>> which
> >>>>> takes a long time) and after that, everything works as normal (even
> >>>>> though I changed nothing related to the NFS), at least for some time,
> >>>>> until digikam again loses connection to the NFS share.
> >>>>> 
> >>>>> Anyone experienced anything like this, or any idea what may be
> >>>>> happening?
> >>>>> 
> >>>>> I'm running Digikam 8.2.0 on Fedora 39 KDE-spin. This is the output (a
> >>>>> little redacted) from "mount" for that share:
> >>>>> 
> >>>>> [server]:[dir_on_server] on [mounting_point] type nfs4
> >>>>> (rw,nosuid,nodev,relatime,vers=4.2,rsize=104857
> >>>>> 6,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,
> >>>>> c
> >>>>> li
> >>>>> ent addr=10.0.0.4,local_lock=none,addr =10.0.0.2,user=xxxxx,_netdev)
> >>>>> 
> >>>>> Thanks much!