-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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]: basicOperation(): Argument #2 ($path) must be of type string, null given #40090
Comments
@simonspa Do you also expierence the issue that COOL is unable to save the document then? In our case a user creates a file in COOL, but when he want's to save it, the issue appears. |
That's a good question @bjo81 that I unfortunately cannot really answer. This only happened in other user sessions so far and I have only observed the above message in the log. I don't know how the UX is in that moment. I will try to inquire with them but since it's been a few days they might not remember. |
I've seen this as well and thought it was an issue in the richdocuments app at first (see nextcloud/richdocuments#3169), but it looks like it's something with the In my case the file in question was shared from a groupfolder, but looking at the enabled apps above, groupfolders are not enabled on your installation, is that correct? So in that case, I can remove groupfolders as the responsible app in my thinking. The error does appear when the user tries to save a (shared with him) document. Sometimes a message pops up saying something about missing permissions and unable to save. The changes are then lost. I've seen this on 27.0.2 and also on 27.1 RC2. Also CC @artonge |
I can definitely confirm that I do not have the group folders app enabled. |
I am wondering if the try-catch is enough here: server/apps/files_versions/lib/Listener/FileEventsListener.php Lines 357 to 365 in cec0b31
if I understand correctly, this calls server/lib/private/Files/Utils/PathHelper.php Lines 38 to 45 in aa241df
But that's just blind guessing on my end since I am not familiar with the code. On my testinstance I have disabled |
@artonge Hi. Can you please take a look? There is a method OCA\Files_Versions\Listener\FileEventsListener::getPathForNode, and it appears that you have created it (commit: 3da63f4). I have studied the operation of this method, and I believe it would make sense to remove the exception handling from it. Why? Example 1 Alice has the file Alice\files\study\homework.odt (file in folder). Example 2 I thought it would make sense to rewrite the exception handling:
\study\homework.odt will then be returned And then in the OCA\Files_Versions\Store::store method there is a Filesystem::file_exists($filename) check against Bob (he has \homework.odt, not \study\homework.odt). As a result, Store::store will not work correctly. Based on these two cases, I have the impression that the system will work more smoothly without handling this exception.
But I have relatively recently started studying Nextcloud, so I would be very grateful if you could evaluate the correctness of these conclusions. |
Hi @AIlkiv |
Beside myself having the problem: see here I found another user from long time/version ago: https://help.nextcloud.com/t/collabora-on-mobile-cant-save-edited-documents-in-shared-folders/69272/2 |
This is not a solution. It should not be used. There was a mistake, I corrected the comment |
Hi @AIlkiv , So, from where my problem comes: $node->getPath() is already And one more thing: your proposal does not work, since I have used this workaround now:
|
@jolly-jump In which case path may not be from the current user? I checked the following situations:
In both cases, I had the correct path. |
I am talking about the situation, where bob edits a file shared from alice.
I admit, I haven't tested a subdirectory like "study" in the account of Alice. Thus: for the webediting everything works already out of the box (the try-part of the exception handling works). For the mobile editing part, the try-part works as well and does not throw an exception, but the relativePath-string is "null", since $node is already the "$ownerNode". Thus the "catch"-part is never reached (in these two situations). |
I get this error trying to run
Any idea what's happening, here? |
When I disable the version app, the problem is solved. |
Could one of you, that experience the issue, apply the following patch and check what kind of file causes the issue for them? |
Applied the patch and re-enabled files_versions. Lets see. I was unable to reproduce it on purpose, only when someone complained that the data they entered in Nextcloud Office was lost. @jakobroehrl Is it reproducable for you each time? |
That was fast, logged the error below. Just to mention it, this happens for me when trying to edit a shared document from the iOS Files app. And I see that @jakobroehrl linked to the Android app. Maybe there's something different when opening richdocuments in a webview in contrast to accessing it through the nextcloud UI?
Exception:
|
Ah, forgot to add |
Thank you for this @jakobroehrl, that's allowing me to actually encrypt files. |
Sure 👍 Here you go: With "marcel.mueller" being the user who shared the file and "test" the user who tried to edit on an iPhone.
|
For testing I moved the logging part to the outside of the if, so it's logged in all cases. When I log in as user "test" and edit the file in Web, this happens:
When I edit the same file on iOS this happens (still user "test"):
|
I experience this every time a office doc was edited by a mobile app. |
FYI, I have this issue, and don't have richdocuments. |
same on my site |
applying this patch while debugging this error also happening within multiboards app the following log comes up:
thing is it does not happen if the logged in user is the same user who created and shared the file of relevance, |
@kyrofa Would you mind sharing your stack trace, too? |
Hey, could one of you test the following PR: #42891 ? |
Hey, couldn't test it too much, but a quick test showed no exception and a version being created! Thanks! |
for me and a quick test it looks like this:
|
Fixed for me with the latest NC version, I actived the version App again. |
Hey, just want to tell you that I'm having the same Problem, disabling Versions solves the Problem it seems. I'm on: No Richdocuments or Office installed. Please tell me if I can do anything to help you figuring this out. |
What could help would be to add the following lines in $this->logger->error('Failed to find relative path for file for ' . $node->getPath() . ' and owner ' . $node->getOwner()->getUID()); And then to trigger the error again, and to post the generated logs here. |
I'm sorry, I gave up on the backup app. I was trying for 2 days and I'm tired of this app. Using Borg now, works like a charm. |
We have the same issue, latest version of Collabora (coolwsd 24.04.1.4) and Nextcloud v28.0.5:
user name 1: the user who I presume created the document |
I am also seeing the exception again. Here is the log as requested:
Notes:
When I add an additional log to the beginning of the
I get:
and a version is created (so user and owner are swapped). What works for me is to still try to get the owner based on the path: diff --git a/apps/files_versions/lib/Listener/FileEventsListener.php b/apps/files_versions/lib/Listener/FileEventsListener.php
index 3273f1f9c40..b3254b0e424 100644
--- a/apps/files_versions/lib/Listener/FileEventsListener.php
+++ b/apps/files_versions/lib/Listener/FileEventsListener.php
@@ -403,6 +403,22 @@ class FileEventsListener implements IEventListener {
}
}
+ // Try to get the owner of the file based on the path as a fallback
+ $parts = explode('/', $node->getPath(), 4);
+ if (count($parts) === 4) {
+ $owner = $parts[1];
+
+ $path = $this->rootFolder
+ ->getUserFolder($owner)
+ ->getRelativePath($node->getPath());
+
+ if ($path !== null) {
+ return $path;
+ }
+ }
+ What I still don't get, why is the user/owner swapped when editing the file on the iOS app in the first place? |
Judging from #44294 (comment) that seems expected. Also nextcloud/richdocuments#3558 recently changed the user when editing, which could also make a difference here I guess. @juliushaertl Maybe there’s a better way to get the path in this scenario with Collabora ? |
I worked on a better approach for storages that do not have a dedicated owner with #44294 nextcloud/groupfolders#2872 That way we would no longer need to get the path but could just use the storage provided user id |
@juliushaertl I upgraded to 30 RC, both PRs are included, still I am unable to edit shared richdocuments files. The only way to make it work is to apply the patch I posted at #40090 (comment). Is there still something missing or should it work? Here's the log:
|
Indeed, i could reproduce that, could you check the patch in nextcloud/richdocuments#3948 and see if that does the trick for you? |
Works fine and resolves this issue for me! |
On Nextcloud 30.0.0RC2, with the PRs applied, I am still getting the error. I am however using group folders, and the file I am trying to open is through a public link. I have R/W access to that file, and it works fine when accessing it through the group folder directly, and it is also okay to open in a private browser (not logged in). The only workaround that still works reliably in my scenario is this: #40090 (comment) Should I open a new bug for this, maybe? |
Please read the last 2 messages, there is a fix coming with the next richdocuments release |
My bad for not mentioning, but I have applied the patch from nextcloud/richdocuments#3948 and it did not resolve the issue for me. (edit: I have also manually checked all the other files mentioned in this bug, and they already have the modifications from the patches. With the added logging from #40090 (comment), I can see the same pattern as this person. Maybe I am missing something, but I cannot see it at the moment.) |
After updating to Nextcloud 30.0.0, and richdocuments to v8.5.0, I still experience the issue. What we are using, and I feel is relevant (feel free to request more)
Log below.
|
Bug description
Yesterday, the below stack trace appeared several hundred times in my Nextcloud 27.0.2 log. From the trace I infer that user BBBB shared an ODS file with user AAAA and the latter is trying to open it (or save it? The user agent is "COOLWSD".)
Whatever is happening, in the end a method requests a string but obtains
null
.Steps to reproduce
(log entries)
Expected behavior
The requested operation succeeds.
Installation method
Community Manual installation with Archive
Nextcloud Server version
27
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.1
Web server
Nginx
Database engine version
MariaDB
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?
Encryption is Disabled
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: