OC\User\NoUserException: Backends provided no user object #19647
Labels
Milestone
Comments
tigernero79
added
0. Needs triage
|
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. |
|
@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? |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
I jus had a look at the stacktrace from #19647 (comment) and the code. The problem seems to be this in the trashbin app ( // check if there is a app which want to disable the trash bin for this file
$fileId = $this->storage->getCache()->getId($path);
$owner = $this->storage->getOwner($path);
if ($owner === false) {
$nodes = $this->rootFolder->getById($fileId);
} else {
$nodes = $this->rootFolder->getUserFolder($owner)->getById($fileId);
}This assumes 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 |
This comment has been minimized.
This comment has been minimized.
|
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. |
|
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: |
|
I have the same problem. Since in #19647 (comment) it was mentioned that |
|
I didn't want to disable the trashbin app, so I wrote a small patch for it that is a bit of an ugly workaround for this issue. But hey, it works for me. :) |
|
Yeah, this won't work for me: I use E-Mail addresses as usernames... |
|
You could also remove the strpos() call and only do the is_string() call, that would work too. |
|
I guess this should be fixed as soon as possible. Or give an easy way to disable trash for remote shares (federated shares). In my opinion this is not a small problem. I hope the enterprise version is not affected. |
|
Issue still present on Nextcloud 20.0.1 (dafault install/update) Issued resolved with this Fix: Worked perfectly when installed on the Nextcloud guest |
|
From what I read here, it seems I'm seeing the same error. I can read from and write to a shared folder that comes from a federated NC v20 instance on my NC v20 instance, but deletion fails with |
|
I get this error wenn I generate previews with the "Preview Generator" app (in connection to OnlyOffice). It seems that the preview generator triggers only office to download the file for preview generation, then the download request fails because of Is this an issue related to the preview app or to the server? |
|
same on AiO 27.1.0 - I get a log every minute or more |
|
I can confirm that. I get this log entry on every cron run (every 5 minutes) on my two NC instances. |
|
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. |
|
Getting this error on 27.1.3 |
|
Me too on 27.1.3, got this in the log: It seems that I got this since I use “group folder” app. ❗ I get this message EVERY minute. |
|
@nickvergessen Latest version used so I'm reopening. Please close if you disagree. |
|
I am getting these errors each an hour in average: ... In the logreader I see: As you can see the errors both in Related to bug nextcloud/groupfolders#2559 |
|
I also have these error messages during my installation. core - OC\User\NoUserException: Backends provided no user object `
`
|
|
There is a fix undergoing here : nextcloud/groupfolders#2640 |
|
Reports are a duplicate of nextcloud/groupfolders#2559 so closing gere. |
|
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. |
|
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. |
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. |
I agree. I don't have that app either and I get the same error. |
|
Where are your logs backtrace? Because "Me too I have the same problem/error/wathever..." means nothing unfortunately... |
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. |
|
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? |
Can't find the error anymore in our logs. Thanks! |
|
After update to Nextcloud v27.1.5 i still have this error in my logs Using Nextcloud 27-fpm Docker with latest pull |
|
@Marcus1Pierce your error is a duplicate of nextcloud/groupfolders#2559 Keep it simple:
|
@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. |
I'm seeing this issue on Nextcloud Hub 8 - version 29.0.2. The error is shown for a user that is deleted. Backtrace: |
|
Seems to be fixed after upgrading my AIO containers. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
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?
The text was updated successfully, but these errors were encountered: