digikam can't find NFS which is actually mounted

[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=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!
>