I am trying to create a private files directory where I can put files that will then not be accessible to anonymous users.
I find directions for this and have tried to follow them carefully.
1) I added this to my settings.php
$settings['file_private_path'] = '../private';
2) I created a .htaccess file inside that directory. (The status report is happy with it.)
3) I have set permissions as:
drwx------
Again, the status report is happy with this.
4) The file system page shows:
Private file system path
../private
An existing local file system path for storing private files. It should be writable by Drupal and not accessible over the web. This must be changed in settings.php
5) I created a specific content type I called "Private File" with a file upload type field which is set to use "Private Files" as the upload destination.
When I create content with this, it indeed puts a file in the private directory as expected.
The file_managed database table shows it as:
private://2026-01/privateFileTest.txt
The problem is that this file can be viewed anonymously. Precisely what I do not want.
Rebuilding cache or node permissions does resolve the issue.
I feel that the problem is a Drupal problem. The reason I say this is because:
I create the private file (privateFileTest.txt) and verify that it can be viewed anonymously (what I do not want to happen), then I rename the file.
At a command prompt, I copy this file to a new file and increment an index number:
privateFileTest1.txt
Now, I try to view the new file anonymously and cannot.
I also cannot view it when logged into the Drupal site.
I understand this to be because Drupal has not created a link to this "system/files" directory for this file.
If I had uploaded the file by creating a new private file, Drupal would have created this link. The problem is, it does not create it privately.
I see a number of modules that seem to perhaps address this issue:
Front Page
Nodeaccess
Node View Permissions
Permissions by Term
Private content
Taxonomy Access Control Lite
Unfortunately, they all seem to be minimally maintained with numerous issues.
I did try Nodeaccess and for a second, thought it resolved the issue only to discover that I could no longer even see the front page and could no longer log in.
Is there a known issue creating a private directory with Drupal 11?
I am working on a Drupal 11 site to replace an existing Drupal 7 site where this functionality is controlled by Organic Groups and seems to work fine.
It looks like Organic Groups is not ready for Drupal 11 yet and I would prefer not to use it.
Is there a good solution for private files? Am I just missing it?
I have gone over this multiple times on both my hosted site and my own VM and get essentially the same results.
Comments
Private files accessible anonymously in Drupal 11 expected beh
In Drupal 8+, private files are not automatically hidden from anonymous users.
If an anonymous user can view the node (or media) that references the file, Drupal will allow them to download the private file.
The private file system only means:
files aren’t directly accessible via the web server
access is checked by Drupal
It does not mean per-role privacy by default.
That’s why:
your uploaded file is accessible anonymously (the node is public)
a manually renamed file isn’t accessible (Drupal doesn’t know about it)
Fix:
Restrict access to the content/media entity:
Remove “View published content” for Anonymous users, or
Use Media + an access module (e.g. Media Entity Access) for finer control
So yes private files are working correctly; access control lives on the entity, not the file.
Private Directory - Drupal 11
Thanks for the prompt reply.
Regarding this suggestions
*Fix:*
Restrict access to the content/media entity:
* Remove “View published content” for Anonymous users, *or*
Yes, I know that if I remove the "View published content" (Role permissions) for Anonymous users, they will not be able to view the "private" files I have uploaded. However, the website has a public and a private portion. There is a certain amount of content (pages and documents and photos) that I DO want anonymous users to be able to access.
If I remove this permission, they lose that access.
The Media Private Access module looks like it has not been updated in a while but perhaps I will check it out.
Use case
It would help if you stated a clear use case. Because you start with:
... and then later, an additional requirement:
So, without mentioning anything Drupal specific, please describe the use case in simple terms, and how you want the system to behave for different users, and which files and nodes they should be able to access, or not: https://www.wrike.com/blog/what-is-a-use-case/
That being said, https://www.drupal.org/project/rabbit_hole or https://www.drupal.org/project/private_content might work.
I tried Rabbit Hole, Field Permissions could work
I tried Rabbit Hole, and it almost seemed to work ... but then I remembered https://www.drupal.org/project/field_permissions which might work? Like an image field, get these extra permission settings:
Field visibility and permissions > Custom permissions > Define custom permissions for this field.
... and you can set a role like "Authenticated user" to "x View anyone's value for field field_image".
The image is now only shown for users with that role, and the image cannot be accessed directly.
Or there's https://www.drupal.org/project/content_access but it all depends on your requirements.
Content Access works really great
I tried https://www.drupal.org/project/content_access as well, and it worked like a charm.
If you set the Article content type to only available for authenticated users, the node is blocked for anonymous users, as well as direct access to any images in the node, if you have set the image field to use Upload destination > Private files.
As a bonus, it supports override on a per node basis, so nodes and their images/files can individually be blocked or available:
Field Permissions does not support this: #1460076: Implement node-level overrides.
The need for finer control
I realize that one of my problems was due to my poor understanding of
the difference between published and unpublished and public and private
and that Drupal in itself does not give the level of control over
content type that I was looking for.
I had been used to Organic Groups and the finer control that it
provided.
Somehow, I thought I had heard that some of this this finer was being
incorporated into Drupal. I don't keep up with Drupal development and
so it has taken me a while to realize that Drupal on its own still does
not give the level of control that I needed.
Thanks for all the comments and suggestions and I will start
investigating some of the many options provided by contributed modules.
It's great that you are
It's great that you are gaining understanding of Drupal's foundation, and I hope you find a good solution.
While Drupal can do a lot out of the box, and if it can be solved with just Drupal core, all the better -- but it's very normal to add contrib modules for specific special needs.
I still think you should consider adding a use case to your post, since we can then guide you to the best solution.
Use Case
My goal is to create a rather basic website using Drupal 11 with several menu options taking anonymous users to various pages giving public content.
The second goal is to create what I call a semi-anonymous user where anyone can log in if they know the credentials. These users will have access to all of the public content mentioned above, of course, but then they will be given access to additional information. It is important this this information is NOT available to anonymous users.
This semi-anonymous user has no permissions to create, edit, or delete content.
The third goal is to be able to create unique accounts for specific people who will then have the ability to create, edit, or delete content that the semi-anonymous user can view.
This was possible with Organic Groups but my understanding is that this module is not yet ready for Drupal 11.
The organic groups module
The organic groups module essentially got replaced by the Groups module, which was easier to work with. I wouldn't expect to see development of the Organic Groups module for D11 in the future. The Group module can be configured to give the level of permissions you need.
https://dgo.to/group
Contact me to contract me for D7 -> D10/11 migrations.
I wouldn't expect to see
Based on the issue activity, work on version 2.x is being actively developed, and the D11 compatible version is also used on 2000 sites, see https://www.drupal.org/project/usage/og
-_-
Moved
OG and breaking changes
Great that OG is being developed, more options is a good thing. ~2000 Drupal 10/11 sites on OG alpha-version is an impressive number of installations, considering this:
But the issue queue has very few issues, and looks maintained, so it could be more stable than that sentence sounds.
Experiment, and see which shoe fits
Thanks for the feedback, that was really useful. And thanks to @jaypan and @wombatbuddy (your OG link has an extra space) for feedback.
While OG and Groups are very powerful, they could be overkill, and add unneeded complexity ... I would advice you to experiment a lot with two scenarios in DDEV (or similar) to be able to speed up the process. Either:
Scenario #:1 Use Drupal core with Content Access
List content
Access
Editors
Scenario #2: OG or Groups
Try out OG or Groups, and see if their added features are needed. In the end, only you know if the complexity they add is too much ...
Considering various options
Thanks to everyone for the suggestions.
I have been hesitant to try "Content Access" because I see this on the module's web page:
This project is not covered by the security advisory policy.
Use at your own risk! It may have publicly disclosed vulnerabilities.
And, I was hesitant to try Groups because I was not certain it was stable either but now I see that I may have been wrong about that.
I will continue investigating the various options suggested.
Great, and while it's true
Great, and while it's true that Content Access is not covered by the security advisory policy, it's a conscious decision, and not necessarily because there are vulnerabilities, though there of course may be.
Did you read the "Security policy" further down on the project page? The project just got a new maintainer, so this decision may not be set in stone ... You could create an issue, and raise a question about it?