digikam can't find NFS which is actually mounted

[Maik Qualmann]

With this commit:

https://invent.kde.org/graphics/digikam/-/commit/
7a1bc7570a88757eebb88b3b9fc716c8b28eade0

The problem should be resolved. If a digiKam version is available to you with 
this change, then do not delete the file UUID in the instance where the 
collection is not available,  but use the collection update function. The 
existing file UUID is used and a new one is not created.

Maik

Am Dienstag, 30. Januar 2024, 20:52:26 CET schrieben Sie:
> I actually didn't think of this scenario, 2 different databases with 2
> computers to the same network share. I'll have to think about something...
> 
> Maik
> 
> Am Dienstag, 30. Januar 2024, 16:12:18 CET schrieb Diego:
> > I found something else. The problem seems to be related to accessing the
> > remote collection from 2 different computers. I have two computers (say
> > A and B) both with digikam using local sqlite databases but the
> > collection is on an NSF share.
> > 
> > NOTE: I always use one or the other; I never use the two simultaneously.
> > So, the problem is not concurrent access.
> > 
> > This is what I see:
> > 
> > 1. If I remove .dtrash/digikam.uuid, I can start from either one and
> > will work normally. This will create a new .dtrash/digikam.uuid file.
> > 
> > 2. Let's suppose I started digikam in computer A and is working fine.
> > Then, I can close digikam, open it again in A, and things still work.
> > 
> > 3. However, if I now open digikam in computer B, digikam cannot find the
> > NFS share even if it's mounted (i.e. I observe what I described in my
> > original post). But if I close digikam, remove .dtrash/digikam.uuid, and
> > restart, thinks are back to normal (as in 1. above) and I can use
> > digikam in computer B.
> > 
> > 4. Once it's working in computer B, I will have the problem in computer
> > A, unless I remove digikam.uuid again.
> > 
> > So, it seems digikam.uuid is tied to the specific client accessing the
> > NFS collection and will not work with the other?
> > 
> > Thanks,
> > 
> > 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
> > >>>>>     =c
> > >>>>>     013
> > >>>>>     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=
> > >>>>>>> sy
> > >>>>>>> s,
> > >>>>>>> c
> > >>>>>>> li
> > >>>>>>> ent addr=10.0.0.4,local_lock=none,addr
> > >>>>>>> =10.0.0.2,user=xxxxx,_netdev)
> > >>>>>>> 
> > >>>>>>> Thanks much!