Return to Answer

I'm using private upload on several sites and can confirm that this works. So no need to file a bug issue.

At this stage I imagined that these settings would cause an uploaded file to go inside the ../private directory. Nope, instead they go into public directory sites/default/files. Was my assumption wrong?

No. This is indeed what should have happened.

So just to make sure, I set up a site to your exact specifications. I.e. with Drupal root in /demo/drupal and the private directory in /demo/private (where / is the Unix file system root).

I first tested it using the absolute path (i.e. /demo/private as the private upload directory). That worked without a glitch.

I then re-tested it using the relative path to the same directory (i.e. ../private). That also worked without a glitch.

I also noted that Drupal threw the following error if I tried to input a non-existing directory as the private upload directory:

Warning: mkdir(): Permission denied in drupal_mkdir()
 (line 2341 of /demo/drupal/includes/file.inc).
 The directory /demo/bogus does not exist and could not be created.

In other words: If Drupal allow you to use ../private as the private upload directory without throwing this error, your setup should work for private upload.

Drupal will automatically place a .htaccess-file in the private upload directory to protect it against prying eyes. However, for best security, the private upload directory should be above the web-root.

PS: As for the file being "served merrily to an anonymous user", this will happen if the anonymous user is granted access to the node the privatly uploaded file it attached to.

All that the "private download method" does, is to extend Drupal's access control system so that files attached to nodes are made inaccesible to those who happen to know their URL. It does so by pretending taht the attachement is stored in the fictitious directory (system/files/). Since this directory does not exist, bypassing Drupal by converting the path into an URL an requesting it directly from the web server to request the file from this directory will not work.

This is different from, and more secure than the "public download method". This method let those who know a file attachement URL bypass Drupal's access control.

I'm using private upload on several sites and can confirm that this works. So no need to file a bug issue.

At this stage I imagined that these settings would cause an uploaded file to go inside the ../private directory. Nope, instead they go into public directory sites/default/files. Was my assumption wrong?

No. This is indeed what should have happened.

So just to make sure, I set up a site to your exact specifications. I.e. with Drupal root in /demo/drupal and the private directory in /demo/private (where / is the Unix file system root).

I first tested it using the absolute path (i.e. /demo/private as the private upload directory). That worked without a glitch.

I then re-tested it using the relative path to the same directory (i.e. ../private). That also worked without a glitch.

I also noted that Drupal threw the following error if I tried to input a non-existing directory as the private upload directory:

Warning: mkdir(): Permission denied in drupal_mkdir()
 (line 2341 of /demo/drupal/includes/file.inc).
 The directory /demo/bogus does not exist and could not be created.

In other words: If Drupal allow you to use ../private as the private upload directory without throwing this error, your setup should work for private upload.

Drupal will automatically place a .htaccess-file in the private upload directory to protect it against prying eyes. However, for best security, the private upload directory should be above the web-root.

PS: As for the file being "served merrily to an anonymous user", this will happen if the anonymous user is granted access to the node the privatly uploaded file it attached to.

All that the "private download method" does, is to extend Drupal's access control system so that files attached to nodes are made inaccesible to those who happen to know their URL. It does so by pretending that the attachement is stored in the fictitious directory (system/files/). Since this directory does not exist, bypassing Drupal by converting the path into an URL and requesting it directly from the web server will not work.

This is different from, and more secure than the "public download method". This method let those who know a file attachement URL bypass Drupal's access control.

I'm using private upload on several sites and can confirm that this works. So no need to file a bug issue.

At this stage I imagined that these settings would cause an uploaded file to go inside the ../private directory. Nope, instead they go into public directory sites/default/files. Was my assumption wrong?

No. This is indeed what should have happened. The weird bit is that you say that uploaded files (still) go into sites/default/files. Where is Drupal picking up that from if you've set the private upload directory to be ../private and selected the private upload method?

Just to make sure, I set up a site to your exact specifications. I.e. with Drupal root in /demo/drupal and the private directory in /demo/private (where / is the Unix file system root).

I first tested it using the absolute path (i.e. /demo/private as the private upload directory). That worked without a glitch.

I then re-tested it using the relative path to the same directory (i.e. ../private). That also worked without a glitch.

I also noted that Drupal threw the following error if I tried to input a non-existing directory as the private upload directory:

Warning: mkdir(): Permission denied in drupal_mkdir()
 (line 2341 of /demo/drupal/includes/file.inc).
 The directory /demo/bogus does not exist and could not be created.

In other words: If Drupal lets use ../private as the private upload directory without throwing this error, your setup should be correct for private upload.

I am sorry not to be of more help. It sounds as you're doing the right ting when setting this up, and I cannot see why it does not work.

What I usually do in cases like this, is to start with a fresh default installation of the core. This usually works. I then re-introduces the modules of my target one by one, testing after each, to identify the module that triggers the problem.

I'm using private upload on several sites and can confirm that this works. So no need to file a bug issue.

At this stage I imagined that these settings would cause an uploaded file to go inside the ../private directory. Nope, instead they go into public directory sites/default/files. Was my assumption wrong?

No. This is indeed what should have happened.

So just to make sure, I set up a site to your exact specifications. I.e. with Drupal root in /demo/drupal and the private directory in /demo/private (where / is the Unix file system root).

I first tested it using the absolute path (i.e. /demo/private as the private upload directory). That worked without a glitch.

I then re-tested it using the relative path to the same directory (i.e. ../private). That also worked without a glitch.

I also noted that Drupal threw the following error if I tried to input a non-existing directory as the private upload directory:

Warning: mkdir(): Permission denied in drupal_mkdir()
 (line 2341 of /demo/drupal/includes/file.inc).
 The directory /demo/bogus does not exist and could not be created.

In other words: If Drupal allow you to use ../private as the private upload directory without throwing this error, your setup should work for private upload.

Drupal will automatically place a .htaccess-file in the private upload directory to protect it against prying eyes. However, for best security, the private upload directory should be above the web-root.

PS: As for the file being "served merrily to an anonymous user", this will happen if the anonymous user is granted access to the node the privatly uploaded file it attached to.

All that the "private download method" does, is to extend Drupal's access control system so that files attached to nodes are made inaccesible to those who happen to know their URL. It does so by pretending taht the attachement is stored in the fictitious directory (system/files/). Since this directory does not exist, bypassing Drupal by converting the path into an URL an requesting it directly from the web server to request the file from this directory will not work.

This is different from, and more secure than the "public download method". This method let those who know a file attachement URL bypass Drupal's access control.

I'm using private upload on several sites and can confirm that this works. So no need to file a bug issue.

At this stage I imagined that these settings would cause an uploaded file to go inside the ../private directory. Nope, instead they go into public directory sites/default/files. Was my assumption wrong?

No. This is indeed what should have happened. The weird bit is that you say that uploaded files (still) go into sites/default/files. Where is Drupal picking up that from if you've set the private upload directory to be ../private and selected the private upload method?

Just to make sure, I set up a site to your exact specifications. I.e. with drupal root in the /demo/drupal and the private directory in /demo/private (where / is the Unix file system root).

I first tested it using the absolute path (i.e. /demo/drupal as the private upload directory). That worked without a glitch.

I then re-tested it using the relative path to the same directory (i.e. ../drupal). That also worked without a glitch.

I also noted that Drupal threw the following error if I tried to input a non-existing directory as the private upload directory:

Warning: mkdir(): Permission denied in drupal_mkdir()
 (line 2341 of /demo/drupal/includes/file.inc).
 The directory /demo/bogus does not exist and could not be created.

In other words: If Drupal lets use ../private as private directory without throwing this error, your setup should be correct for private upload.

I am sorry not to be of more help. It sounds as you're doing the right ting when setting this up, and I cannot see why it does not work.

What I usually do in cases like this, is to start with a fresh default installation of the core. This usually works. I then introduces modules one by one, testing after each, to identify the module that triggers the problem.

I'm using private upload on several sites and can confirm that this works. So no need to file a bug issue.

At this stage I imagined that these settings would cause an uploaded file to go inside the ../private directory. Nope, instead they go into public directory sites/default/files. Was my assumption wrong?

No. This is indeed what should have happened. The weird bit is that you say that uploaded files (still) go into sites/default/files. Where is Drupal picking up that from if you've set the private upload directory to be ../private and selected the private upload method?

Just to make sure, I set up a site to your exact specifications. I.e. with Drupal root in /demo/drupal and the private directory in /demo/private (where / is the Unix file system root).

I first tested it using the absolute path (i.e. /demo/private as the private upload directory). That worked without a glitch.

I then re-tested it using the relative path to the same directory (i.e. ../private). That also worked without a glitch.

I also noted that Drupal threw the following error if I tried to input a non-existing directory as the private upload directory:

Warning: mkdir(): Permission denied in drupal_mkdir()
 (line 2341 of /demo/drupal/includes/file.inc).
 The directory /demo/bogus does not exist and could not be created.

In other words: If Drupal lets use ../private as the private upload directory without throwing this error, your setup should be correct for private upload.

I am sorry not to be of more help. It sounds as you're doing the right ting when setting this up, and I cannot see why it does not work.

What I usually do in cases like this, is to start with a fresh default installation of the core. This usually works. I then re-introduces the modules of my target one by one, testing after each, to identify the module that triggers the problem.