<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>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):<br>
</p>
<p><span style="font-family:monospace"><span
style="color:#000000;background-color:#ffffff;">digikam.database:
Creating new Location "/" uuid
"networkshareid:?mountpath=/mnt/compart_bebu_b/Pictures&fileuuid=c013b4e8-f234-46</span><br>
9a-901e-b3dc7f04a88d"
<br>
digikam.database: Found Location "/mnt/compart_bebu_b/Pictures"
with file uuid "37698a21..."
<br>
digikam.database: Location for "/mnt/compart_bebu_b/Pictures" is
available: false => case sensitivity: 2<br>
<br>
</span>I'm attaching the complete output just in case it adds more
info.<br>
</p>
<p>Thanks,<span style="font-family:monospace"><br>
</span></p>
<p>Diego<span style="font-family:monospace"><br>
</span></p>
<div class="moz-cite-prefix">On 1/29/24 12:05, Maik Qualmann wrote:<br>
</div>
<blockquote type="cite" cite="mid:2670108.lGaqSPkdTl@linux-tpgn">
<pre class="moz-quote-pre" wrap="">If the collection is not recognized, create a log of the debug output of
digiKam in the terminal as described here:
<a class="moz-txt-link-freetext" href="https://www.digikam.org/contribute/">https://www.digikam.org/contribute/</a>
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:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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,client
addr=10.0.0.4,local_lock=none,addr =10.0.0.2,user=xxxxx,_netdev)
Thanks much!
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
</body>
</html>