After upgrading to filefield 3.13, I get the error "Referencing to the file used in the field is not allowed." when attempting to save any page that has existing imagefield items.

Members fund testing for the Drupal project. Drupal Association Learn more


Infinitee’s picture

I am experiencing the same problem on a Drupal 6 site...

"Referencing to the file used in the field is not allowed."

This error appears upon attempting to edit any field of any page containing a filefield image.

After much research it appears that this is due to a bug in the filefield module and only seams to be occurring since the latest security update of Drupal 6.32 core.

I found that by deleting the current filefield image and either replacing it with a new or, the same image that the page can then successfully be saved and without the error message. Unfortunately, this does not fix the problem and the filefield image needs to be deleted every time an edit is made.

Needless to say, this is not a preferred way of editing pages but, it does work for now.

zanix’s picture

I am having this issue as well. Looks like the last update added some security checks to the uploaded files.

  if ($item['fid'] != 0) {
    if (function_exists('file_download_access') && $item['status'] && !file_download_access($item['filepath'])) {
      $element['preview'] = array(
        '#type' => 'markup',
        '#value' => t('Access denied'),
    else {
      $element['preview'] = array(
        '#type' => 'markup',
        '#value' => theme('filefield_widget_preview', $item),
zanix’s picture

And this line

if (field_file_references($file) == 0 || (function_exists('file_download_access') && !file_download_access($file->filepath))) {
cdale’s picture

It looks like the checks fail when the file download method is set to public, as the core drupal function uses hook_file_download() to count the number of headers returned. However, when the download method is public, most modules don't return any headers.... That's what I'm seeing at least.

This should probably check what the file download method is, and only run the access check if file downloads are private.

thalemn’s picture

I am experiencing this issue with Drupal 6 after upgrading Filefield to 6.x-3.13.

In many cases I have too many files attached to the node to do what comment #1 suggests (although I did have success with this when only one item was attached).

What is our solution?

zanix’s picture

My solution was to revert the code back to version 6.x-3.12

thalemn’s picture

OK - that's what I did, too.

David_Rothstein’s picture

Title: Referencing to the file used in the field is not allowed. » Referencing to the file used in the field is not allowed after 6.x-3.13 security update
Priority: Normal » Critical
Related issues: +#2305017: Regression: Files or images attached to certain core and non-core entities are lost when the entity is edited and saved

This looks like the Drupal 6 equivalent of the problem in the Drupal 7 core File module, so I'm adding a link to that.

David_Rothstein’s picture

Title: Referencing to the file used in the field is not allowed after 6.x-3.13 security update » "Referencing to the file used in the field is not allowed" error after 6.x-3.13 security update
othermachines’s picture

I have two 6.x sites that have been updated to 6.x-3.13, so of course I immediately started testing. I wasn't able to solve this problem, but here are some observations that will hopefully nudge this along:

* Even though I have content types with both 'filefield' and 'image' fields attached, I wasn't able to duplicate the problem exactly as described. There are other factors at play here. This means more details may be needed to track this down.

* In the one instance where I was able to generate the error, it was because a destination subfolder was missing. In the absence of the file_download_access($file->filepath) check, this would have passed FileField's validation before. Now, it causes filefield_file_download() to query the {files} table using an empty $filepath string. I have no idea if this is related.

* @cdale said we shouldn't be checking for # of headers on public files, which is probably true, but I don't think that's the problem here. FileField will always return a header unless something else goes wrong.

* Possibly interesting that in both cases where posters pasted in the error, the field title is missing. It should be "Referencing to the file used in the [field title] field is not allowed." That means $element['title'] is missing, which should only happen in the case of a field where multiple values are allowed. That said and for what it's worth, one of my content types did have a filefield field permitting multiple values, and still I was unable to reproduce the error.

I've run out of time so just wanted to put that out there, in case it helps.

quicksketch’s picture

Thanks @othermachines for all the debugging. When I tested this in 3.12, everything was working fine with a normal FileField and even with FileField Sources.

@David_Rothstein is correct that we should be able to pull the similar fix from the Drupal 7 issue and apply it to FileField.

dmitrii’s picture

Status: Active » Needs review
1.38 KB

Patch for #4

theunraveler’s picture

It looks like the ends of the lines in the patch in #12 may have been cut off. Here's a good version of the patch.

thalemn’s picture

Thank you for submitting the patch. Worked perfectly.

nagba’s picture

The patch looks good code review-wise. I can also confirm that the patch solves the issue.
anyone else wants to do code review / test or shall we push the ticket to 'reviewed & tested by community' ?

yan’s picture

Status: Needs review » Needs work

Same problem here with Drupal 6.32 and Filefield 6.x-3.13. The patch from #13 doesn't solve the problem in my case. The server is running PHP Version 5.3.3. The file method is public. Another website running at the same ISP but on a different server (also with PHP 5.3.3) doesn't have that problem.

othermachines’s picture

@yan - Can you please describe the problem? Also, what type of node and, if the node is created by a module, which one? Is it a filefield or image field and does it permit multiple values? Thanks -

** Edit - also, what action did you take after applying the patch? Did you attempt to save a node and an error persisted?

TrevorBradley’s picture

Patch #13 worked for me. Thanks!

danyg’s picture

1.43 KB

Patch #13 is almost correct. Only problem is FILE_DOWNLOAD_PRIVATE. This defined variable is FILE_DOWNLOADS_PRIVATE properly.

daveparrish’s picture

#13 worked well for me too.

subsonik’s picture

Having the same problem. The root cause is filefield_file_download() denying access to the file referenced in the filefield.

Apparently, if you're referencing an existing file, filefield_file_download() will create a list of node revisions where this file is referenced. Next, it will loop those node revisions to find out whether or not you have access to the node revision.

The problem is filefield_file_download() stops looping those node revisions as soon as it finds a single node where the user doesn't have access, instead of continuing to loop until it finds a node where the user DOES have access...

Anyways, patch #13 works by circumventing the problem, but the root cause is still there imho.

reikiman’s picture

I tried the patch in #19, and it worked on my site

mishunika’s picture

I have the exactly same issue and the patch from #19 seems reasonable and it fixes the issue.

ZoeN’s picture

Same problem here, patch #19 works.

haggins’s picture

Confirming patch #19 is working.

SiliconMind’s picture

Status: Needs work » Reviewed & tested by the community

Any chance we can get this committed?

dr.admin’s picture

Same problem, patch #19 works.

cybergigz’s picture

Confirming patch #19 is works.

joelpittet’s picture

Here's the same patch but relative to the filefield module.

joep.hendrix’s picture

#19 works

askibinski’s picture

#19 works

rajmataj’s picture

#29 worked for me. Thanks!

pslcbs’s picture

#29 worked for me too. Thanks!

squarecandy’s picture

ferrangil’s picture

Patch #29 worked just fine. Thank you.

maxferrario’s picture

Thanks a lot for the patch: #29 worked for me!

askibinski’s picture

Status: Reviewed & tested by the community » Needs work

This patch only seems to fix the issue when the file system is public. It will still return the form error when in private mode.

dkinzer’s picture

There is an error with the code as written in 6.x-3.13:

See the following test case:

  echo (TRUE && $step = TRUE && $step) ? "PASSED" : "FAILED";

The above fails because $step is not available in the third section even though it's defined earlier in the predicate chain. Yet, this is precisely the type of logic that is being used to determine access to file fields. Thus, false negatives are possible whenever access relies on code using said logic.

The following patch fixes this particular issue, but it requires that the user have access to view the specific node revision that get's checked when said node revision is not equal to the current node revision.

Note, that I couldn't find a tag for the current 6.x-3.13 version of filefield in the Git repo, so this patch is against 6.x-3.13 that I downloaded from

You'll need to run `patch -p1 < filefield-2305969-38-fix-predicate.patch` in order to apply it.

PS I noticed on my site that certain file fields were attached to node revisions that were not part of the current node revisions. I still don't know why the revisions are off. But I only see this issue when revisions for the files are not the same as current revision.

dkinzer’s picture

Status: Needs work » Needs review
dkinzer’s picture

Here's the same patch but with both #19 and #38.

halbtuerke’s picture

I'm using a private file system and the patch from #40 isn't working on my site. I still get the error message for every file I have in the specific post I want to edit.

dkinzer’s picture

@halbtuerke does the user also have permission for viewing node revisions... because I notice that's the only thing that #40 fixes.

halbtuerke’s picture

@dkinzer I've used an administrator account which has all rights.

yan’s picture

Patch from #40 seems to solve the problem for me.

joep.hendrix’s picture

Patch from #40 seems to solve the problem for me.

ShaneOnABike’s picture

Status: Needs review » Reviewed & tested by the community

This works fine if the file has already been referenced, but if it isn't referenced then it won't work. I think that this was always the 'slightly' annoying case.

So from my perspective with a public system it's a go!

@halbtuerke - perhaps you could add more debug info to find out where it is failing as it would be nice to move this along.

halbtuerke’s picture

@ShaneOnABike - What kind of debug information would be helpful and how do I get this kind of information?

Thanks in advance

ShaneOnABike’s picture

You could debug the code to see which part of the if statements are failing? Using devel is a good start... then the patch can be modified accordingly to handle the private system better. Perhaps the private system isn't even reaching that section of patched code?

MakeOnlineShop’s picture

Hello, I just started to have this problem, no module update has been released ? So we should use the previous version ?

Could you tell me if I will have problems after trying to put back the 3.12 without updating the database ? Just by changing the files in the module directory ?

Thank you.

yan’s picture

This issue still forces me to use an unsecure version of the module. Could somebody commit the proposed patch to prevent that?

ghmercado’s picture

#40 worked for me

halbtuerke’s picture

@ShaneOnABike - As I currently don't have the means to debug the production environment nor do I have the time to properly setup a local copy of the system, you can go ahead and consider this as fixed as it seems that for everyone else the patch fixes the problem.

Thanks for the help.

iantresman’s picture

#40 worked for me, would be nice to see the module updated to include the fix.

sonoutlaw’s picture

#40 was the silver bullet... thanx dkinzer

jiaqi.yin’s picture

Agree with #21, the patches can fix the problem, but the root cause is about the permission of node view and node filefield view which is checked in filefield_file_download()

if (($node = node_load($content['nid'])) && (node_access('view', $node) && filefield_view_access($field_name, $node))) {
  // They have access to the node.
  $denied = FALSE;

In our case, we had exactly the same issue, and it turned out this is because the user doesn't have the "view field_file" permission (field_file is the field name in one of the content types, would be different from yours). So by granting the corresponding node view and field view permissions, we can edit the node page again.

It is worth of checking your role permissions before applying patches.

BenMirkhah’s picture

#40 worked for us too thank you.

meanbeth’s picture

Thanks, dkinzer. #40 worked for us too.

Wish this were in the latest module release.

pwolanin’s picture

Would be helpful if someone could improve the issue summary including concise steps to reproduce the bug.

Weka’s picture

Thank you dkinzer, patch provided in #40 works.

pwolanin’s picture

Status: Reviewed & tested by the community » Needs review
2.23 KB
630 bytes

i think patch #40 is missing one bit of logic to check that the node actually got loaded.

sindyy’s picture

The patch solved my problem. Thanks!

  • pwolanin committed d0701af on 6.x-3.x
    Issue #2305969 by dkinzer, pwolanin, dmitrii, joelpittet, danyg,...
pwolanin’s picture

Status: Needs review » Fixed
aiphes’s picture

is a new version planed or we must to patch the last one ?

pwolanin’s picture

yes, I'll roll another release after checking over the issue queue some more

aiphes’s picture

great,because patching (on a dev version + dumped db) doesn't work for will wait :)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

MakeOnlineShop’s picture


Can you confirm that only a patch has been released ? No working module ?

Thank you.

MakeOnlineShop’s picture

No update on this ?

rares’s picture

I downloaded the 3.x-dev code here, however the filefield.module didn't match with the changes in the patch. It might be that what is currently packaged as dev is an older version...
In the end, I applied the changes manually (, and the uploads now work properly.

alexharries’s picture

I have applied the patch in #40 and it has worked for me. Yay!

Please can we get this two-year-old issue committed into the codebase? :-)

Thank you!

drupalinthailand’s picture

Hello, I have the same problem with the latest version.

So only 3.12 is working correctly ?

Thank you.

tinem’s picture

On my site with Drupal 6.37 FileField 6.x-3.13 I discovered some problem with some of my images not working as espected when using an API-file for getting data into to my apps with some of my code as:

    foreach ($fields as $field) {
      $source_name = 'field_' . $field;
      $field_value = $toilet->$source_name;
      if (is_array($field_value)) {
        $xml_toilet->$field = $field_value[0]['value'];

    if (count($toilet->field_image) > 0 && $toilet->field_image[0]['filepath'] != '') {
      $xml_images = $xml_toilet->addChild('images');
      foreach ($toilet->field_image as $image) {
        $xml_image = $xml_images->addChild('image');
        $xml_image->mime_type = $image['filemime'];
        $xml_image->url = url($image['filepath'], array('absolute' => true));

  // Render XML
  drupal_set_header('Content-Type: application/xml; charset=utf-8');
  print $xml->asXML();

One day Android app stopped functioning because of "<mime_type/>" which should have been <image> <mime_type>image/jpeg</mime_type> <url> </url> </image>and sometimes images in apps were NOT showed but OK on online site. Hope you understand and someone have time to answer
and if this will functioning again if I upgrade to FileField 6.x-3.14, please?