"Download Link" is invisible for authorized user (roles). Permission does not work on .zip files!!

I had the same issue yesterday. In my case, as I can see, the reason of this problem was that all affected files' type was "undefined" in the file_managed table and also mime type of these files wasn't mapped to any pre-defined file types (document, image, video, audio) by file entity module. Because type was "undefined" file_entity_file_entity_access() returned FILE_ENTITY_ACCESS_IGNORE, so file_entity_access() continued with this
if ($op == 'view' && is_object($file)) {}
statement and because the operation was "download", this functioned returned with FALSE in the 1733 line so auth. users could not download files which type was "undefined".

There are workarounds for this problem of course. You can ensure that the type of files is one from the pre-defined ones programmatically (ex.: in hook_file_presave()) or you can define new file types on the UI (admin/structure/file-types/add) and add mime types of your files to this new file type. After that you just need to ensure that current user roles has right to "Download {any,own} XY files" on the permission page.
Other solution could be is implementing you own file access logic by implementing hook_file_entity_access() in a custom module.

But I'm wondering, would not be better if we would modify the file_entity_access() function to handle not only the view operation but also the download operation as well? We could use the same logic here, which would mean that we need to introduce new permissions like:

• Download private files
• Download own private files
• Download own files
• Download files

That's a great writeup @mxr576

I agree that the permanent solution should be configuring download action permissions.
In the meantime, I like the hook_file_entity_access route and use view action to determine whether the user should be able to download the file.
I cannot think of a scenario of where I'd allow a user to "view" but not "download" the file (not to say there aren't any).

Something like the following should work:

/**
 * Implements of hook_file_entity_access().
 * This is a workaround until download action gets its own permission set.
 */
function your_custom_module_file_entity_access($op, $file, $account) {
  // Check to see if the user has access to view the file. If they do, let them download it.
  if ($op == 'download' && file_entity_access('view', $file, $account)) {
    return FILE_ENTITY_ACCESS_ALLOW;
  }

  // Doesn't allow or deny access, it allows original file_entity_access to finish execution and make a decision.
  return FILE_ENTITY_ACCESS_IGNORE;
}

Any news about this bug ? I have tons of files my users can't download because files are .zip :(

Go to Structure -> File types -> Document
Append in the Mimetypes field the following:

application/zip

Thanks @mxr576 and @spesic.

I've created a patch, which not only checks for $op == 'view' but also for $op == 'download' in file_entity_access() function.

Please review the patch, my first local tests on a project were positive, but we're also testing further.

Another try. Call file_entity_access() function itself as with $op = 'view' as fall back for $op = 'download'

Please review.

I cannot think of a scenario of where I'd allow a user to "view" but not "download" the file (not to say there aren't any).

@spesic, I'm totally agree with you on that. I don't know why the tests are failing, but I guess simply changing the order of tests would solve this issue. I took a short look at the tests and see that the test user gets 'view files' permission before the tests for download.

So with that patch checking the view permissions as well, the test user can download the file even if it doesn't have neither 'download own document files' nor 'download any document files'.

I'll try to create a new patch with the tests re-ordered so that tests for download permissions come before the tests for view permissions.

Next attempt with re-ordered tests.

Hi All,

I am facing this issue again on Drupal 8. Please help.

new patch

knock on wood, this should pass tests.

added one line:

$file->status = FILE_STATUS_PERMANENT;

just the line before file_save() in the test

had a closer look at the patch, it makes no sense.

I haven't actually noticed this issue yet, likely outdated.

Might be worthwhile taking a closer look again.

Hi all,

I can confirm this issue is still happening. I have an Entity file and even though anonymous have permission to see files, if I setup the "Downlod Link" field formatter from DS, only admin is able to see the output and download the file.

Copy the URL of the button, and pasting it in an incognito window, gives the access denied.

I have also tried to add PDF as a Mime type in its own, still doesn't work.

I just had to deal with this on a Drupal 7 site.
I needed the public file to be available to anyone.
So, I made quick and dirty DS field that gets the job done.

/**
 * Implements hook_ds_fields_info().
 */
function mymodule_ds_fields_info($entity_type) {
  $fields = [];

  // Other fields here on the real site...

  $fields['node']['census_excel_as_download_link'] = [
    'title' => t('Excel file as download link (mymodule.module)'),
    'field_type' => DS_FIELD_TYPE_FUNCTION,
    'function' => 'mymodule_ds_field_census_excel_as_download_link',
    'ui_limit' => ['data_census|full'],
  ];

  if (isset($fields[$entity_type])) {
    return [$entity_type => $fields[$entity_type]];
  }

  return [];
}

/**
 * Callback for 'Census Data excel file as download link' field.
 */
function mymodule_ds_field_census_excel_as_download_link($field) {
  $markup = '';
  if (!empty($field['entity']->field_data_file_upload[LANGUAGE_NONE][0]['uri'])) {
    $file_uri = $field['entity']->field_data_file_upload[LANGUAGE_NONE][0]['uri'];
    $file_url = file_create_url($file_uri);
    $markup = l(t('Download Table in Excel Format'), $file_url);
  }
  return $markup;
}

I thought I needed this patch, but it was related to the mime type as others have mentioned. After adding the mime-type for my new files (application/octet-stream) I then had to go update the records in `file_managed` table to have the correct type of `document`. They were `undefined` since the mime type wasn't associated with the file type at upload time. Not saying that's the fix for this issue (maybe), but hopefully that helps others!

This looks more like a support request and a documentation issue.

Solution is to correctly configure your mime types as discussed in comment #23
Other use cases/scenarios may want to have a look at the solution discussed in comment #24

I haven't yet added any documentation for this but would be willing to review a patch that updates the README.txt file.