Passwords helps trigger "This file no longer exists" error

🍱 Features & apps passwords
1

I have been trying for a few months to investigate an error I’m getting in accessing Nextcloud files via the web interface, when the files are part of a group folder. I will occasionally and intermittently receive a “This file no longer exists” error when clicking on a file (for example a PDF or JPG, but probably any file). The error also seems to occur for files shared from other users, and in fact possibly any file that is not normally part of the user’s account. The error occurs after some timeout (maybe a few seconds to a minute) and is cleared by accessing the files root directory. (In fact, when the system can’t find a sub-directory, it will land in the root, which then clears the problem for a while.)

I’ve been trying to investigate via using log statements and source code inspection, and this problem seems to have something to do with losing the mount point information, which causes the system to look for the file in the user’s local file area rather than the group folder area. However, I’m not very familiar with the architecture yet.

Why I mention this here is that I just found that Passwords can trigger the problem, though maybe it’s not the only way to trigger it. I have a test installation for which I could not previously reproduce the problem … Until I created a password. The creation or access of a password details seems to trigger the error immediately (e.g. two tabs open – one for passwords and one for the file).

This problem doesn’t seem to be widespread among other users (maybe reported by one other person), so I’m wondering if it has to do with my installations (I have three now that can reproduce the problem), but I don’t know enough about the architecture to make a lot of progress myself. I’m also not sure if anyone else can actually reproduce the problem … although now I know Passwords might help in reproducing the problem.

Is there something in Passwords that might trigger the system to forget the mount points? I know this is a long shot, but two of these systems are in active use and I hate to try to re-install to clear up the problem. And now I’m not even sure if that would lead to a stable system.

Earlier this year I updated to the latest PHP because the default PHP shipped with Ubuntu 22.04 was causing intermittent crashes. I’m currently using PHP 8.2.11. I also did a few other optimizations a that time, although backing them out doesn’t seem to fix the problem. I’m using the latest stable Nextcloud, 27.1.3, though this has been happening for a few revisions now.

Thanks in advance for any information you could provide.

2

I’m actually able to reproduce this with mount points created trough the External Storage app. If i navigate in the passwords app or reload the data from the server in the browser extension, the next attempt to navigate within a mounted folder fails.

The passwords app and the browser extension both use the API with an individual access token. So they don’t actually use the current browser session and they don’t send any cookies.
In theory the app, extension and your open files app should appear as three different clients to the server. There shouldn’t have any influence on each other, but it seems like they do.

I think the reason is that the passwords app creates tokens without the “Allow filesystem acces” permission:
grafik

As soon as i add this permission to the token my browser extension uses, the issue disappears. Too bad i can’t add the permission to the token used by the webinterface.

If you want, you can test this with the browser extension:

  • Just add/remove the permission from the token used by the extension.
  • Go into the mounted folder
  • Open the extension, go to the third tab (“Browse”). Hover over the name of the server and then click the refresh button to the right.
  • Try to navigate in the mounted folder

(You need to use the extension with an app token for this.)

My guess would be that there is some issue with how NC handles this permission. If you look into the code of the passwords app, you can see that there is already on exception where the permission is added.

3

Thanks!

I wonder how I could take this information forward to get the problem solved at the root of it. Hmm …