<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>I always mount the NFS first. But just to try now, I unmounted
it, open digikam and then mounted. Still the same problem. <br>
</p>
<p>I do have a .dtrash/digikam.uuid with a timestamp from 1/14/2024
(perhaps the first time this started? I don't recall...)<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 15:10, Maik Qualmann wrote:<br>
</div>
<blockquote type="cite" cite="mid:2145915.9o76ZdvQCi@linux-tpgn">
<pre class="moz-quote-pre" wrap="">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:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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:
</pre>
<blockquote type="cite">
<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,
c
li
ent addr=10.0.0.4,local_lock=none,addr =10.0.0.2,user=xxxxx,_netdev)
Thanks much!
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
</body>
</html>