digikam can't find NFS which is actually mounted

[Maik Qualmann]

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!