I will say now that I'm not a Drupal pro, but I can usually hold my own.  This one has me stumped.

My private files directory is at sites/default/files/private and is called out as such in settings.php:

# $settings['file_private_path'] = ‘sites/default/files/private’;

But of course, that isn't recognized on my site even after clearing the cache.  I suspect that the # is the issue as it's basically commenting out the process of setting the path.  I tried removing the #, uploading settings.php to the server, and then my site crashes (it returns the "This site has experienced a problem..." error).  I cannot access update.php or clear the cache in this state.  Undoing the change in settings.php, uploading it, and then running update.php brings the site back.

So, I'm at a loss.  The # causes my path to be ignored and removing it causes my site to break.  Does anyone have any advice?

Thanks in advance!

Comments

websiteworkspace’s picture

The pound sign comments out the line .. 

Meanwhile, if you are going to create a "private files" directory, it should ideally be outside of the site docroot.

Often a fully qualified path in your account's directory hierarchy, or at your docroot, but one directory above, is ideal. For example, in my server I run more than one site, so I have multiple sub-directories at - /home/username/websiteprivatefiles/*

$settings['file_private_path'] = '/home/username/websiteprivatefiles/www.mysite.tld';

(note - the /home/username/ * convention may vary depending on linux version and other software installed)

nce you have created a private files directory, you will also need to take additional steps to restrict access to the files by deploying support to restrict access to the content that presents the private files. 

Keep in mind that anybody can just click "view source" and find the URL for your "private" file, unless you have restricted access to the content/page that presents the otherwise "private" file(s). 

A great module to implement fine grained content access restrictions is:

https://www.drupal.org/project/content_access

which has proven very reliable. 

--

There are numerous other modules that you may want to evaluate. You will probably want to setup a special module testing site to evaluate these before trying to deploy them on the actual site you are creating. 

(no endorsement implied)

https://www.drupal.org/project/private_files_download_permission

https://www.drupal.org/project/protected_file

https://www.drupal.org/project/file_view_access

https://www.drupal.org/project/file_utility

--

other related (tertiary) modules:

https://www.drupal.org/project/ajax_file_download_counter

https://www.drupal.org/project/filebrowser

https://www.drupal.org/project/audiofield

- a superb module for hosting audio files
- choose soundmanager2 bar-ui presentation style

 

slewazimuth’s picture

$settings{'file_private_path'] = '../private_files';

Sets the directory private_files to one level above the site root. ie. Accessible to Drupal but not visible to the web. Works perfectly for uploading files with something like IMCE.

ugintl’s picture

@slewazimuth it worked. Remember to clear cache

shellebelle’s picture

I'm unfortunately still having difficultly with this.

I was able to sort out the path to give to 'file_private_path' in settings.php, so my site's not breaking anymore (yay).  To make a long story short, I now have my private files ('private_files') directory above the site root, which is 'public_html'.  File System can see it just fine (it does show it within single quotes if that matters), but Drupal is returning an error:

----

FILE SYSTEM

Writable (public download method)

The directory ‘private_files’ does not exist. You may need to set the correct directory at the file system settings page or change the current directory's permissions so that it is writable.

-----

'private_files' is most certainly there on my server.  Its permissions are set that the owner can read/write/execute, and group and public are only allowed to read/execute.  Any advice?

Thank you!