-
-
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]: File Ownership Transfer through Web UI fails with TypeError: OC\Files\Node\HookConnector::getNodeForPath(): Argument #1 ($path) must be of type string, null given
#38889
Comments
Please find the entry for |
Here's the relevant entry from the logfile:
FYI, background jobs are running under cron. Let me know if you need more info. Thanks. |
I can reproduce with current master. |
We're seeing the same issue on 26.0.2. |
cc @come-nc |
Same here, migrated to 26.0.2 this morning, Error occurred 2 times until now. |
The problem is this line: server/lib/private/Files/View.php Line 171 in 75d5fa4
It compares the root of the file path with the views fake root, and that fails for the transferring user. User Alice (transferring) has path |
Possibly a regression from #36774 |
Using Even though "remote user" is just a placeholder for the cron user doing its thing, it still could lead people to think someone nefarious has access to the system. |
TypeError: OC\Files\Node\HookConnector::getNodeForPath(): Argument #1 ($path) must be of type string, null given
Bug description
Transferring ownership of files fails with an error code. While notifications as described in the documentation are received, and the receiving folder is created, the final file transfer seems to fail. The files remain in their original location on my account.
Maybe I'm missing something or I misconfigured something?
Steps to reproduce
Note that the user's receiving folder titled transferred from on was created.
Expected behavior
After second user clicks Accept, second user should receive a copy of the files in the indicated folder. Also, I expected that the files would disappear from my account.
Installation method
Community Manual installation with Archive
Nextcloud Server version
26
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?
Updated from a MINOR version (ex. 22.1 to 22.2)
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: