<html><body><div dir="ltr"><div>

    </div><div><div dir="ltr">If the NFS is not mounted when you open DigiKam, it won't find it!</div><div dir="ltr"><br></div><div dir="ltr">Nadine H</div>

    <div id="ms-outlook-mobile-signature" dir="ltr"><div></div></div>

<div> </div><hr style="display:inline-block;width:98%" tabindex="-1"><div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif"><b>From:</b> Digikam-users <digikam-users-bounces@kde.org> on behalf of Diego <eldieguisimo@gmail.com><br><b>Sent:</b> Monday, January 29, 2024 4:19 PM<br><b>To:</b> Maik Qualmann <metzpinguin@gmail.com>; digikam-users@kde.org <digikam-users@kde.org><br><b>Subject:</b> Re: digikam can't find NFS which is actually mounted<div> </div></font></div>I just removed the .dtrash/digikam.uuid file (actually I moved it to 

<br>another place) and digikam is working again as expected. It generated a 

<br>new .dtrash/digikam.uuid with a different uuid inside. Not sure how to 

explain this.

<br>

<br>Diego

<br>

<br>On 1/29/24 15:10, Maik Qualmann wrote:

<br>> Is it possible that your NFS collection is not yet mounted when you start

<br>> digiKam? But the path is writable and there is no file UUID. And since we have

<br>> a UUID in the DB create a new one? Ok, this scenario is possible, but we can

<br>> fix it. We can no longer do without the UUID file, since under macOS the

<br>> partition UUID changes with every OS update. We use UUID file in order to

> recognize the collection.

<br>>

<br>> If the NFS is not mounted, please check whether there is a .dtrash/

<br>> digikam.uuid file?

<br>>

<br>> Maik

<br>>

<br>> Am Montag, 29. Januar 2024, 21:50:14 CET schrieben Sie:

<br>>> Thanks Maik -- this is a mystery for me too. Nothing changed in the

<br>>> remote collection or the local box. I'm just closing digikam, turning

<br>>> off the computer, coming back again the next day turning the computer

<br>>> on, mounting the NFS share, and starting digikam. I'm not an expert in

<br>>> 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?

<br>>>

<br>>> Perhaps there is a way to disable the UUID method if it causes trouble,

>> and fall back to the old on directory name?

<br>>>

<br>>> Diego

<br>>>

<br>>> On 1/29/24 12:49, Maik Qualmann wrote:

<br>>>> OK, the old method doesn't work here because we found both a file UUID in

>>> the database and in the collection.

<br>>>> So the question is, why aren't they the same? A collection cloned onto the

>>> NAS or something similar?

<br>>>>

<br>>>> Maik

<br>>>>

<br>>>> Am Montag, 29. Januar 2024, 19:41:48 CET schrieben Sie:

>>>> The saved file UUID c013b4e8... differs from the file UUID 37698a21...

<br>>>>> found in the collection. The question is, why? What did you do? The

<br>>>>> technology is new, but I have no idea how this can happen. In addition,

<br>>>>> the old method of detection of the collection would still apply in this

<br>>>>> case.

<br>>>>>

<br>>>>> Maik

<br>>>>>

<br>>>>> Am Montag, 29. Januar 2024, 19:28:41 CET schrieben Sie:

<br>>>>>> Thanks Maik. Here seems to be the relevant output (the share mounting

<br>>>>>> point is /mnt/compart_bebu_b/ and Pictures/ is the directory where the

<br>>>>>> pictures are):

<br>>>>>>

<br>>>>>> digikam.database: Creating new Location  "/"  uuid

<br>>>>>>

<br>>>>>>     "networkshareid:?mountpath=/mnt/compart_bebu_b/Pictures&fileuuid=c013

<br>>>>>>     b4e

<br>>>>>>     8-

<br>>>>>>

<br>>>>>> f234-46 9a-901e-b3dc7f04a88d"

<br>>>>>> digikam.database: Found Location "/mnt/compart_bebu_b/Pictures" with

<br>>>>>> file uuid "37698a21..."

<br>>>>>> digikam.database: Location for "/mnt/compart_bebu_b/Pictures" is

<br>>>>>> available: false => case sensitivity: 2

<br>>>>>>

>>>>> I'm attaching the complete output just in case it adds more info.

<br>>>>>>

<br>>>>>> Thanks,

<br>>>>>>

<br>>>>>> Diego

<br>>>>>>

<br>>>>>> On 1/29/24 12:05, Maik Qualmann wrote:

<br>>>>>>> If the collection is not recognized, create a log of the debug output

<br>>>>>>> of

<br>>>>>>> digiKam in the terminal as described here:

<br>>>>>>>

<br>>>>>>> https://www.digikam.org/contribute/

<br>>>>>>>

<br>>>>>>> At the moment one could only guess. For a network collection,

<br>>>>>>> digiKam-8.2.0

<br>>>>>>> and above uses two functions to recognize that the collection is

<br>>>>>>> mounted

<br>>>>>>> and that it is the correct one. On the one hand, the new file UUID (the

<br>>>>>>> file is in the .dtrash path), but as a fallback, the old method from

<br>>>>>>> the

>>>>>> path and at least one folder/file must be present.

<br>>>>>>>

<br>>>>>>> Maik

<br>>>>>>>

<br>>>>>>> Am Montag, 29. Januar 2024, 17:20:11 CET schrieb Diego:

<br>>>>>>>> Hi -- somehow digikam seems to be losing its information about NFS

>>>>>>> shares even though the NFS is successfully mounted on the system.

<br>>>>>>>> These

<br>>>>>>>> is all the evidence I have:

<br>>>>>>>>

<br>>>>>>>> 1. When I double click on a picture I get a message "The storage

>>>>>>> location of this image is currently not available".

<br>>>>>>>>

>>>>>>> 2. When I open digikam, it finishes searching for new items in 0 secs.

<br>>>>>>>> This is odd since it typically takes between 1 or 2 mins)

<br>>>>>>>>

<br>>>>>>>> 3. When I go to settings -> configure digikam -> collections. I see my

<br>>>>>>>> network share, but the little "network symbol" next to it, is grayed

<br>>>>>>>> out.

<br>>>>>>>>

<br>>>>>>>> 4. On the right pane, under the "Properties" tab, the Folder (under

<br>>>>>>>> "File Properties") starts with "???/" instead of the mounting point of

>>>>>>> the NFS as it should.

<br>>>>>>>>

>>>>>>> 5. On a terminal, I can "df" or "mount" and see the filesystem there.

<br>>>>>>>> In

<br>>>>>>>> fact I can cd and open and pictures/movies with gwenview, mplayer,

<br>>>>>>>> vlc,

<br>>>>>>>> etc. So, the NFS share is definitely mounted and accessible (I can

<br>>>>>>>> also

<br>>>>>>>> write on it).

<br>>>>>>>>

<br>>>>>>>> 6. If in settings/configure digikam/collection I click on the circular

<br>>>>>>>> arrows next to the NFS path which says "updates the path of the

<br>>>>>>>> collection" and select exactly the same directory as before, it starts

<br>>>>>>>> rescaning everything (and I think rebuiliding the database, all of

<br>>>>>>>> which

<br>>>>>>>> takes a long time) and after that, everything works as normal (even

<br>>>>>>>> though I changed nothing related to the NFS), at least for some time,

>>>>>>> until digikam again loses connection to the NFS share.

<br>>>>>>>>

<br>>>>>>>> Anyone experienced anything like this, or any idea what may be

<br>>>>>>>> happening?

<br>>>>>>>>

<br>>>>>>>> I'm running Digikam 8.2.0 on Fedora 39 KDE-spin. This is the output (a

<br>>>>>>>> little redacted) from "mount" for that share:

<br>>>>>>>>

<br>>>>>>>> [server]:[dir_on_server] on [mounting_point] type nfs4

<br>>>>>>>> (rw,nosuid,nodev,relatime,vers=4.2,rsize=104857

<br>>>>>>>> 6,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,

<br>>>>>>>> c

<br>>>>>>>> li

<br>>>>>>>> ent addr=10.0.0.4,local_lock=none,addr =10.0.0.2,user=xxxxx,_netdev)

<br>>>>>>>>

<br>>>>>>>> Thanks much!

<br>>

<br>>

<br>>

<br></div></div></body></html>