When an anonymous user is editing an entity with private files they can get the following error: "You do not have access to the referenced entity (file: file_id)."

Change the specific gender in the title.

I had the exact same issue but, in my case, it's when accessing public files from a logged-in user. When saving the node form, I get "You do not have access to the referenced entity (file: file_id)".

First, it seems I had to return AccessResult::allowed() in my hook_file_access when the URI scheme was "public://", which is weird because if I'm not mistaken it used to work before. Doing this, then FileAccessControlHandler deal with the file access and return allowed for "public" scheme.

So after that, the access on the file was allowed, but form validation will fail on ReferenceAccessConstraintValidator for the reason you explained.

Comparing the two ids indeed do the trick, and I don't think $referenced_entities = $existing_entity->{$value->getFieldDefinition()->getName()}->referencedEntities(); would ever return an array keyed by entity ids.

+1 for this patch.

I suddenly started getting reports of the "You do not have access to the referenced entity (file: file_id)." error from a client. After some debugging I ended up inside the code in question and I agree with the sentiment here. If the point here is to not check access for files already referenced by the entity, as per the comment in the code, then this didn't seem to work correctly previously.

I'm not sure what caused these errors to start appearing in this project, but I've been able to reproduce the error in one scenario so far, and adding this patch fixed that one scenario at least.

In my case I have a custom content entity with an image field with private file storage. I was able to reproduce this error by having two different users try uploading files to the same entity. The ease of reproducing this caused me to try the same with a normal node type as well, but I wasn't able to reproduce the error there. Maybe I could have if I fiddled more with the permissions, or nodes just have different permissions than custom content entities anyway.

<?php
// each of a delta-keyed array
foreach ($referenced_entities as $ref) {  
  // $ref->id() points to fid in my case which is e.g. 3018, soooo....
  if (isset($referenced_entities[$ref->id()])) { 
    // never hits here
  }
}
?>

+1 for the patch, existing code makes no sense, at least in my use case of "10 files attached to a user profile".

Having tested this patch, can confirm it removes the immediately offending errors.

It didn't fix an underlying problem with access checks that I'm having, but this was definitely blocking progress.

Thanks for reporting this issue.

I'm not sure if this is the correct fix or not, but either way, we would definitely need an automated test that fails without the fix and passes with it. Tagging "Needs tests" for that. Thanks!

I had this problem with an authenticate user and user_picture in the public folder.

The patch did not work, at first. It did work once I changed the storage of the user_picture to private.

I didn't have time to investigate further, ping me if you anyone wants more details. (And it's strange because it worked a couple of days ago with the public folder, and no patch.).

Crossing my fingers it holds.

Ok, we will send you a white dove with a message...

I can confirm this patch works on a D9.4.11 PHP8.1 site. I don't have this problem anymore on D9.5.x sites

Just ran into this issue after updating from Drupal 9 to Drupal 10 for existing media entities. No ideas why this comes up now, but perhaps something related was fixed, which is now causing this issue...?

For me the issue came up as Administrator editing a media entity (document) with a private file fields. I wasn't able to save the media entity anymore with the existing value and also got access denied trying to open the file.
This patch fixed the issue for me! Now I'm able to save the form again.

Thanks for the patch, ran into the same problem as @Anybody listed. In my case though only in a media field (not private) provided in a paragraph, was only discovered by accident because this field is rarely used. The patch fixes the problem, successfully tested on Drupal 10.1.6

RTBC++

I will try to create test case.

I created test as described in the IS, but I was not able to get the error on 10.2.x-dev.
Issue targeted on 10.1.x let's see how pipeline will result.

I was not able to reproduce the issue.
You can check test case in the MR.
Needs more info, how to reproduce it.

Oops.
Made commit to wrong branch.
Revert changes.

Initial patch didn't work for me, so attaching the patch, which fixed the issue.
My issue is following:
1) Drupal 9.5.11, webform module 6.1.5, default download method is private
2) There is webform, which is accessible by anonymous users and contains upload field of type `Document file`.
3) When admin tries to update submission via edit page `admin/structure/webform/manage/form_name/submission/1/edit`, there is same error, as mentioned in title.
Not sure, if my fix is proper one, but it seems logical to check `download` operation instead of `view` for files, which can be downloaded, but can't be viewed.

I stumbled across this problem because we're getting the same error message when we try to update a user entity via a REST module that references a field containing multiple private files.

The problem is clearly that the check on the `$referenced_entities` array in `ReferenceAccessConstraintValidator::validate()` expects the keys to be IDs. In our case, however, the keys are numerically indexed consecutively starting at 0. Therefore, the fix in the first patch in this ticket generally resolves the issue.

We are on Drupal 10.6 and the REST PATCH request does not touch the file reference or the field at all. We are even logged in via an API token, so no anonymous access. The user has all relevant permissions set.