Repository navigation
OC\User\NoUserException: Backends provided no user object #19647
Copy link
Copy link
Closed as not planned
Labels
0. Needs triagePending check for reproducibility or if it fits our roadmapPending check for reproducibility or if it fits our roadmap27-feedbackbug
Milestone
Description
I use two nextcloud updated to version 18.0.1 and I have problem in deleting files from a shared federated folder. while nextcloud user who shared my folder with me you can safely operate the files I who received the federated folder I can upload the images but not delete them although on another instance I have permissions on the folder for editing. I get this error "OC \ User \ NoUserException: Backends provided no user object" how can I solve?
Attach complete error:
[webdav] Fatal: OC\User\NoUserException: Backends provided no user object at <<closure>>
0. <<closure>>
OC\Files\Node\Root->getUserFolder("[email protected]/")
1. /var/www/Pensierando/nx/lib/private/Files/Node/LazyRoot.php line 65
call_user_func_array([OC\Files\Node\Root {},"getUserFolder"], ["[email protected]/"])
2. /var/www/Pensierando/nx/lib/private/Files/Node/LazyRoot.php line 282
OC\Files\Node\LazyRoot->__call("getUserFolder", ["[email protected]/"])
3. /var/www/Pensierando/nx/apps/files_trashbin/lib/Storage.php line 142
OC\Files\Node\LazyRoot->getUserFolder("[email protected]/")
4. /var/www/Pensierando/nx/apps/files_trashbin/lib/Storage.php line 182
OCA\Files_Trashbin\Storage->shouldMoveToTrash("2020-02-23_161848.jpg")
5. /var/www/Pensierando/nx/apps/files_trashbin/lib/Storage.php line 100
OCA\Files_Trashbin\Storage->doDelete("2020-02-23_161848.jpg", "unlink")
6. /var/www/Pensierando/nx/apps/files_accesscontrol/lib/StorageWrapper.php line 287
OCA\Files_Trashbin\Storage->unlink("2020-02-23_161848.jpg")
7. /var/www/Pensierando/nx/lib/private/Files/View.php line 1162
OCA\FilesAccessControl\StorageWrapper->unlink("2020-02-23_161848.jpg")
8. /var/www/Pensierando/nx/lib/private/Files/View.php line 716
OC\Files\View->basicOperation("unlink", "/Cartella Con T ... g", ["delete"])
9. /var/www/Pensierando/nx/apps/dav/lib/Connector/Sabre/File.php line 448
OC\Files\View->unlink("/Cartella Con T ... g")
10. /var/www/Pensierando/nx/3rdparty/sabre/dav/lib/DAV/Tree.php line 179
OCA\DAV\Connector\Sabre\File->delete()
11. /var/www/Pensierando/nx/3rdparty/sabre/dav/lib/DAV/CorePlugin.php line 287
Sabre\DAV\Tree->delete("files/Tiger/Car ... g")
12. <<closure>>
Sabre\DAV\CorePlugin->httpDelete(Sabre\HTTP\Reque ... "}, Sabre\HTTP\Response {})
13. /var/www/Pensierando/nx/3rdparty/sabre/event/lib/EventEmitterTrait.php line 105
call_user_func_array([Sabre\DAV\CorePlugin {},"httpDelete"], [Sabre\HTTP\Requ ... }])
14. /var/www/Pensierando/nx/3rdparty/sabre/dav/lib/DAV/Server.php line 479
Sabre\Event\EventEmitter->emit("method:DELETE", [Sabre\HTTP\Requ ... }])
15. /var/www/Pensierando/nx/3rdparty/sabre/dav/lib/DAV/Server.php line 254
Sabre\DAV\Server->invokeMethod(Sabre\HTTP\Reque ... "}, Sabre\HTTP\Response {})
16. /var/www/Pensierando/nx/apps/dav/lib/Server.php line 319
Sabre\DAV\Server->exec()
17. /var/www/Pensierando/nx/apps/dav/appinfo/v2/remote.php line 35
OCA\DAV\Server->exec()
18. /var/www/Pensierando/nx/remote.php line 165
require_once("/var/www/Pensie ... p")
DELETE /remote.php/dav/files/Tiger/Cartella%20Con%20Tiger/2020-02-23_161848.jpg
from 37.160.88.102 by Tiger at 2020-02-25T21:10:45+00:00
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
0. Needs triagePending check for reproducibility or if it fits our roadmapPending check for reproducibility or if it fits our roadmap27-feedbackbug
Activity
tigernero79 commentedon Feb 26, 2020
in practice, those who receive the federated folder from another nextcloud despite having the permissions to delete, cannot delete files that only the one who shared the federated folder puts in that folder, while I, who received the shared folder in my nextcloud, can only files but don't delete them as well if other has given me the permissions.
tigernero79 commentedon Feb 26, 2020
@nickvergessen I read that you committed to the problem that I have on nextcloud 12,
nextcloud/files_downloadactivity#8
but now I run on instance nextcloud 18.0.1 and I still have that error on the federated shared folders where those who shared can delete the files and those who receive the federated folder it cannot delete the files inside despite having received the permissions. how to solve?
pilsetnieks commentedon Apr 28, 2020
arjan-s commentedon Jul 8, 2020
aimotrens commentedon Jul 23, 2020
arjan-s commentedon Jul 23, 2020
uPvtkBlpiucvDUf commentedon Jul 29, 2020
I jus had a look at the stacktrace from #19647 (comment) and the code. The problem seems to be this in the trashbin app (
OCA\Files_Trashbin\Storage::shouldMoveToTrash):This assumes
$owneris eitherfalseor a user. However, for federated shares,$owneris something like[email protected]/, which is neitherfalsenor a user. As a result,$this->rootFolder->getUserFolder($owner)raises an exception and the delete operation fails.The problem seems to have been introduced in this commit: 8e7c287. I think the trashbin behavior needs to be adjusted to work with federated shares. Unfortunately, I don't know enough about nextcloud internals to know how the trashbin should be correctly handled in this case.
@rullzer Can you help?
Fwiw: I can reproduce this issue on 19.0.1 and when it occurs I can also reproduce this other issue: nextcloud/desktop#853 regarding high CPU usage of the desktop client. This high CPU usage occurs precisely after I receive a federated share and then try to delete a file in this share (which fails as described above). If I remove the federated share, also the desktop client syncing issue is gone. The reason seems to be that the server always sends a new
Etagto the client for the federated share so that the client is constantly syncing (according to logs recorded withnextcloud --logdebug). I will write a more detailed comment about this when I find the time.fettfoen commentedon Jul 31, 2020
khlschrnk commentedon Sep 12, 2020
I also got this problem since a a long time. Now, with 19.0.3 it's still appearing in my log at every run of cron.
kiplingw commentedon Sep 19, 2020
I am experiencing the same problem on 19.0.3. Remote user shared a folder with me. They have given me full permissions to create, edit, and delete. I am able to do all of but the latter. The logs show the following stack trace:
andyboeh commentedon Oct 5, 2020
I have the same problem. Since in #19647 (comment) it was mentioned that
files_trashbincould be the problem, I disabled the "Deleted Files" app on the receiving cloud (it's still enabled on the sharing server). I could then delete the shared folder without a problem.31 remaining items
solracsf commentedon Dec 13, 2023
Reports are a duplicate of nextcloud/groupfolders#2559 so closing gere.
k00ni commentedon Dec 13, 2023
I am confused why this is a duplicate of nextcloud/groupfolders#2559, when this one is over 2 years older than the linked issue. This issue also contains more information about the problem and tested configurations. It was closed in the meantime but reopened. It seems there is some confusion around here.
solracsf commentedon Dec 13, 2023
No there isn't. Problem is that people see "Backends provided no user object" in the error log and thinks "this is the same issue" while it is not the same issue. All recents reports (this year reports) on this issue are related to GroupFolders app, not Server.
So, it is a duplicate since the issue must be tracked on GroupFolders repo, not here.
dgsiegel commentedon Dec 13, 2023
I don't think this is the case, as we don't have the GroupFolders app installed. It only happens with public shares in our instance, see my comment (#19647 (comment)) above.
adriangalbincea commentedon Dec 13, 2023
I agree. I don't have that app either and I get the same error.
solracsf commentedon Dec 13, 2023
Where are your logs backtrace?
Because "Me too I have the same problem/error/wathever..." means nothing unfortunately...
dgsiegel commentedon Dec 14, 2023
There are plenty of log backtraces already in this issue, but here you go:
I get this error accessing a public share with read&write permissions enabled. I'm accessing that folder via curl and rclone and using the share's id as well as a password to upload and edit files in that folder.
solracsf commentedon Dec 14, 2023
Good.
#41786 has been shipped with v27.1.5 (or v28), released today, it can help in this case.
Can you test and report back?
If this does not help, please provide a JSON backtrace.
dgsiegel commentedon Dec 15, 2023
Can't find the error anymore in our logs. Thanks!
Marcus1Pierce commentedon Dec 17, 2023
After update to Nextcloud v27.1.5 i still have this error in my logs
Using Nextcloud 27-fpm Docker with latest pull
All Nextcloud Apps up to date
solracsf commentedon Dec 17, 2023
@Marcus1Pierce your error is a duplicate of nextcloud/groupfolders#2559
Keep it simple:
/groupfolders/lib/Versions/VersionsBackend.phpis present in the backtrace, it is a duplicate of Backends provided no user object / Duplicate entry for key 'gf_versions_uniq_index' groupfolders#2559 in this case please also make sure you're using Group Folders app version v16.0.1. If these 2 conditions are met (line is present and app is v16.0.1) report on groupfolders repo.Marcus1Pierce commentedon Dec 18, 2023
@solracsf Sorry i though it the same think. I didn't read your comment before.
If i check groupfolders v16.0.1 is available in Nextcloud v28. I think i can't upgarde to Nextcloud 28 for now. And for Nextcloud v27.1.5, latest version of groupfolders is 15.3.1.
thompol commentedon Sep 15, 2024
I'm seeing this issue on Nextcloud Hub 8 - version 29.0.2. The error is shown for a user that is deleted.
Backtrace:
thompol commentedon Sep 15, 2024
Seems to be fixed after upgrading my AIO containers.