<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Correct. The problem is that digikam can't find it when it is
actually mounted before starting digikam. <br>
</p>
<div class="moz-cite-prefix">On 1/30/24 04:30, Nadine Helkenn wrote:<br>
</div>
<blockquote type="cite"
cite="mid:41A7E279-9F2D-4340-B388-8638E9A3F7A8@hxcore.ol">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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> </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
<a class="moz-txt-link-rfc2396E" href="mailto:digikam-users-bounces@kde.org"><digikam-users-bounces@kde.org></a> on behalf of Diego
<a class="moz-txt-link-rfc2396E" href="mailto:eldieguisimo@gmail.com"><eldieguisimo@gmail.com></a><br>
<b>Sent:</b> Monday, January 29, 2024 4:19 PM<br>
<b>To:</b> Maik Qualmann <a class="moz-txt-link-rfc2396E" href="mailto:metzpinguin@gmail.com"><metzpinguin@gmail.com></a>;
<a class="moz-txt-link-abbreviated" href="mailto:digikam-users@kde.org">digikam-users@kde.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:digikam-users@kde.org"><digikam-users@kde.org></a><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 <br>
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
<br>
> 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
<br>
>> 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,
<br>
>> 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
<br>
>>> the database and in the collection.
<br>
>>> So the question is, why aren't they the same? A
collection cloned onto the
<br>
>>> NAS or something similar?
<br>
>>>
<br>
>>> Maik
<br>
>>>
<br>
>>> Am Montag, 29. Januar 2024, 19:41:48 CET
schrieben Sie:
<br>
>>>> 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>
>>>>>
<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>
>>>>>> <a class="moz-txt-link-freetext" href="https://www.digikam.org/contribute/">https://www.digikam.org/contribute/</a>
<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
<br>
>>>>>> 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
<br>
>>>>>>> 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
<br>
>>>>>>> location of this image is
currently not available".
<br>
>>>>>>>
<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
<br>
>>>>>>> the NFS as it should.
<br>
>>>>>>>
<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,
<br>
>>>>>>> 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>
</blockquote>
</body>
</html>