digikam can't find NFS which is actually mounted

Tue Jan 30 12:41:19 GMT 2024

Correct. The problem is that digikam can't find it when it is actually 
mounted before starting digikam.

On 1/30/24 04:30, Nadine Helkenn wrote:
> If the NFS is not mounted when you open DigiKam, it won't find it!
>
> Nadine H
> ------------------------------------------------------------------------
> *From:* Digikam-users <digikam-users-bounces at kde.org> on behalf of 
> Diego <eldieguisimo at gmail.com>
> *Sent:* Monday, January 29, 2024 4:19 PM
> *To:* Maik Qualmann <metzpinguin at gmail.com>; digikam-users at kde.org 
> <digikam-users at kde.org>
> *Subject:* Re: digikam can't find NFS which is actually mounted
> I just removed the .dtrash/digikam.uuid file (actually I moved it to
> another place) and digikam is working again as expected. It generated a
> new .dtrash/digikam.uuid with a different uuid inside. Not sure how to
> explain this.
>
> Diego
>
> On 1/29/24 15:10, Maik Qualmann wrote:
> > 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!
> >
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20240130/34b51f87/attachment.htm>