-
-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Trouble accessing data for certain users: "Exception thrown: OCP\Files\GenericFileException" when Rich Workspaces is enabled w/ external storage and ldap #42663
Comments
Something makes me think the final error in that stack trace may be a red herring, but to semi-rule that out you can try disabling rich workspaces globally to see if there is any change: Are there any other log entries from the point of trying to log-in and the provided stack trace? It might be informative to lower your loglevel temporarily, to |
Hi @joshtrichards , Thanks for you quick feedback ! Well, it looks like you've found the problem. One :
Fix the problem, everything working's again. If i re-active rick workspace :
The problem returns. FYI, here are the logs when log verbosity is set on
Can we consider this a bug with the latest server version (28.0.1)? Thanks again for your help ! |
We have the same issue but without SMB shares. |
@svenseeberg Anything else similar to the original reporter's environment? LDAP auth perhaps? |
Or the The bit of code here has been tweaked a few times for performance (though not recently). I think lines 116-128 more properly belong up under the For example, I don't see any problem in a stock install (i.e. without LDAP). |
I can confirm the issue - and the workaround mentioned in this comment above . The weird thing is: we have ~10 Users all but one via LDAP. Only one had trouble accessing their files, others seemed fine. Thank you for the quick workaround, and have a nice day :) |
I had same issue
fixed it |
Sorry for the late answer. Yes, LDAP Auth.
And this is also true in my case. |
I have the same issue. From my experience, it occurs only for folders where a user doesn't have read permissions to all objects within. |
I don't think this is in any way related to encryption or LDAP - I had the same issue for a WebDAV external storage, and the proposed workaround To clarify: My instance does not use LDAP authentication, nor does it use sever-side encryption. |
same problem here. as soon as I disable it it works. |
Same problem here, NC 28.0.5, LDAP enabled. Log
{
"reqId": "wUyGLN68GLTPX9hjr4xA",
"level": 3,
"time": "2024-05-23T07:26:33+00:00",
"remoteAddr": "xxx",
"user": "xxx",
"app": "webdav",
"method": "PROPFIND",
"url": "/remote.php/dav/files/xxx/",
"message": "Exception thrown: OCP\\Files\\GenericFileException",
"userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:126.0) Gecko/20100101 Firefox/126.0",
"version": "28.0.5.1",
"exception": {
"Exception": "OCP\\Files\\GenericFileException",
"Message": "",
"Code": 0,
"Trace": [
{
"file": "/data/nextcloud_a1/apps/text/lib/DAV/WorkspacePlugin.php",
"line": 119,
"function": "getContent",
"class": "OC\\Files\\Node\\File",
"type": "->"
},
{
"file": "/data/nextcloud_a1/3rdparty/sabre/dav/lib/DAV/PropFind.php",
"line": 95,
"function": "OCA\\Text\\DAV\\{closure}",
"class": "OCA\\Text\\DAV\\WorkspacePlugin",
"type": "->",
"args": [
"*** sensitive parameters replaced ***"
]
},
{
"file": "/data/nextcloud_a1/apps/text/lib/DAV/WorkspacePlugin.php",
"line": 117,
"function": "handle",
"class": "Sabre\\DAV\\PropFind",
"type": "->"
},
{
"file": "/data/nextcloud_a1/3rdparty/sabre/event/lib/WildcardEmitterTrait.php",
"line": 89,
"function": "propFind",
"class": "OCA\\Text\\DAV\\WorkspacePlugin",
"type": "->"
},
{
"file": "/data/nextcloud_a1/3rdparty/sabre/dav/lib/DAV/Server.php",
"line": 1052,
"function": "emit",
"class": "Sabre\\DAV\\Server",
"type": "->"
},
{
"file": "/data/nextcloud_a1/3rdparty/sabre/dav/lib/DAV/Server.php",
"line": 984,
"function": "getPropertiesByNode",
"class": "Sabre\\DAV\\Server",
"type": "->"
},
{
"file": "/data/nextcloud_a1/3rdparty/sabre/dav/lib/DAV/Server.php",
"line": 1662,
"function": "getPropertiesIteratorForPath",
"class": "Sabre\\DAV\\Server",
"type": "->"
},
{
"file": "/data/nextcloud_a1/3rdparty/sabre/dav/lib/DAV/Server.php",
"line": 1647,
"function": "writeMultiStatus",
"class": "Sabre\\DAV\\Server",
"type": "->"
},
{
"file": "/data/nextcloud_a1/3rdparty/sabre/dav/lib/DAV/CorePlugin.php",
"line": 346,
"function": "generateMultiStatus",
"class": "Sabre\\DAV\\Server",
"type": "->"
},
{
"file": "/data/nextcloud_a1/3rdparty/sabre/event/lib/WildcardEmitterTrait.php",
"line": 89,
"function": "httpPropFind",
"class": "Sabre\\DAV\\CorePlugin",
"type": "->"
},
{
"file": "/data/nextcloud_a1/3rdparty/sabre/dav/lib/DAV/Server.php",
"line": 472,
"function": "emit",
"class": "Sabre\\DAV\\Server",
"type": "->"
},
{
"file": "/data/nextcloud_a1/3rdparty/sabre/dav/lib/DAV/Server.php",
"line": 253,
"function": "invokeMethod",
"class": "Sabre\\DAV\\Server",
"type": "->"
},
{
"file": "/data/nextcloud_a1/3rdparty/sabre/dav/lib/DAV/Server.php",
"line": 321,
"function": "start",
"class": "Sabre\\DAV\\Server",
"type": "->"
},
{
"file": "/data/nextcloud_a1/apps/dav/lib/Server.php",
"line": 373,
"function": "exec",
"class": "Sabre\\DAV\\Server",
"type": "->"
},
{
"file": "/data/nextcloud_a1/apps/dav/appinfo/v2/remote.php",
"line": 35,
"function": "exec",
"class": "OCA\\DAV\\Server",
"type": "->"
},
{
"file": "/data/nextcloud_a1/remote.php",
"line": 172,
"args": [
"/data/nextcloud_a1/apps/dav/appinfo/v2/remote.php"
],
"function": "require_once"
}
],
"File": "/data/nextcloud_a1/lib/private/Files/Node/File.php",
"Line": 56,
"message": "",
"exception": {},
"CustomMessage": "Exception thrown: OCP\\Files\\GenericFileException"
}
}
|
Had the same problem. No LDAP, but user files where on SMB share. Setting |
Same problem here. NC 29.0.3 and 29.0.4. Fixed with proposed fix here (although I used the GUI to just entirely disable the 'Text' app). Users authenticate via LDAP plugin. External storage is a local volume that is mounted over NFS outside of NC. |
Same problem here. NC 29.0.4. "Fixed" with proposed fix. More info here: https://help.nextcloud.com/t/after-updating-to-29-0-4-users-have-lost-access-to-the-local-file-system/198810/6 |
It looks like a good idea to wrap The exceptions are documented in the file class. server/lib/private/Files/Node/File.php Lines 25 to 30 in dae7c15
The case, that the file content is unavailable for whatever reason, should not break the propfind request. It could be related to #37943. |
Makes sense. cc @elzody i think you had a similar report where we did not have logs when we talked about that. |
With "file content" are you refering to "external storage"? If yes, I would like to point to an aspect, which might play a role here: In my installation, i have 3 external storages, all in the same subnet and connections are up. However, i run into this issue unless I turn off rich workspace. Now, while searching for the root case, i was looking into the database and in the oc_storages table i not only found these 3 configured external storages (with all its related records per user) which are also shown in the UI plus the records for the local storages, but a bunch of additional records pointing to external storages which have been deleted a long time ago and which do not show up in the UI. Some thoughts regarding these (potential) findings:
Since i don't know the intention of the developers regarding the "external storages old db records deleteion process" i have not done a deeper investigation. In case the developers think this could be an issue, just ping me and I will support tracking this down as good as i can (if needed). |
Just applied nextcloud/text#6155, set occ config:app:set text workspace_available --value=1 and a short test confirms the problem i encountered is gone now (files are shown on local and external storages). -- However, there still are tons of GenericFileExceptions in the logs (don't seem to come from the same code but at the same time seem to be related to the text app):
-- Also, i found:
I don't know which behaviour is intended by the developers, but from a user point of view, this looks inconsistent and maybe indicates another issue. |
Isn't that just the content of the README.md file on your sftp storage? ;) |
Mind checking the xhr response in your browser's network tools? It should contain the error message and make it easier for us to figure out the problem. |
Yes, it is. So there it's working correctly. Just waned to document that the basic mechanism seems to work. |
The problem i reported above i was able to track down to issues in the handling of file permission in the related php smb library. So it's not related to this tickets root cause. |
Bug description
Hi everyone,
We have a whole group of LDAP users who connect to the Nextcloud with external storage (SMB/CIFS) that maps automatically as soon as the user logs on.
Since upgrading to 28.0.1, some users are accessing network folders but nothing is visible (No files) and I'm getting generation errors at the same time :
So the network folder is accessible, but when it is accessed, everything remains empty and an error is generated.
I can't reproduce the problem for everyone, only for certain users. For example, user
A
will have access while userB
won't (even though on the Active Directory and Nextcloud sides they have exactly the same rights and permissions, they're practically identical profiles).I came across an issue that seems similar, as we also use Collabora :
https://help.nextcloud.com/t/ocp-files-genericfileexception-in-file-php-nach-occ-app-update-all/175085/2
Despite deactivating the richdocuments and richdocumentscode plugins, nothing to do still the same. I've also disabled preview and ACL checking in the external storage settings, but the problem persists. I also have the same problem if I create a share manually from the user account, in addition to the share done automatically at login.
I also tried to delete the LDAP user from Nextcloud but it was impossible ((Is it possible to force the deletion and then reconnect as if from scratch? That would be a good idea) :
I also deleted his Nextcloud user profile folder, then reconnected, but that didn't work.
The size of the folder is displayed, and you can access it (a sign that the link is working), but as soon as you access it, everything is empty.
Steps to reproduce
Expected behavior
The contents of the folder are displayed.
Installation method
None
Nextcloud Server version
28
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.2
Web server
Nginx
Database engine version
MySQL
Is this bug present after an update or on a fresh install?
Upgraded to a MAJOR version (ex. 22 to 23)
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
No response
The text was updated successfully, but these errors were encountered: