Managed files on a private file-system that do not have references from other entities can not be downloaded or viewed. Or styled using Drupal core's "image styles". This stems from lingering assumptions in Drupal 7 core that files are properties or meta data attached to other entities, instead of first class citizens (or entities) in their own right.
Specifically, this code in file_file_download() (an implementation of hook_file_download() in core's file.module) prevent access to the file. It was introduced in Drupal 7 in "
#898036: Private images broken →
". And later extended to handle edge cases:
// Stop processing if there are no references in order to avoid returning
// headers for files controlled by other modules. Make an exception for
// temporary files where the host entity has not yet been saved (for example,
// an image preview on a node/add form) in which case, allow download by the
// file's owner.
if (empty($references) && ($file->status == FILE_STATUS_PERMANENT || $file->uid != $user->uid)) {
return;
}
hook_file_download() or create a dummy entity with references to all files just for this case. But neither of those are clean solutions.Conceptually, File Lock module should also solve the problem described here. However File Lock module solves the problem by adding a row to the file_usage table, while file_file_download() uses an EntityFieldQuery to look for entities that reference the file.
File Lock module could be changed to handle both cases via a dummy entity. This is cleaner than doing so inside File Entity or Media modules.
file_file_download() could instead use the file_usage table which would be simpler, more performant and make it more extensible in cases like this. However that would also be a core patch and would still not help to fix Drupal core's broken assumptions about Files.Similar: #1351906: Importing image fails on private file system. → .
#1351906 may be duplicate but the subject suggests that the import fails. While here the issue is downloading/viewing files that were successfully uploaded (or imported). I expect that the same issue will occur with imported images as they will also be "orphaned" as per Drupal 7 core's assumptions. I have not tested that case.
Also; I am not sure if the solution to this problem is best discussed in File Entity module's issue queue, or that of Media module, Drupal 7 or 8 core, possibly File Lock module's or a combination of the above. That probably depends on the solution(s) that are agreed to be most appropriate.
Needs work
11.0 🔥
file system
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Marking this as a feature request.
IMO this should be closed as works as designed. We certainly cannot suddenly start exposing all orphaned files on existing sites to the public.
Given this is how private files have worked for ~15 years or more, I don't think we should change this in core. As per #1, you can change this in a contrib or custom module using hook_file_download.