When I upload files using the upload module the permissions are being set so that no one can access them. How would I go about changing the permissions the upload module sets on a file?

Comments

rj.seward’s picture

I have the same problem. I upload a file and an ls -al shows it has been uploaded as follows:

>ls -al
-rw------- 1 apache apache 23552 Jul 7 16:04 tmp_QwXZVW
...

but Drupal kicks out an error that appears to say it's not there:

The selected file /var/www/html/drupal/files/tmp/tmp_QwXZVW could not be uploaded, because the destination is not properly configured.

in admin/settings/file-system I have Temporary directory set to files/tmp (with permissions are set to 777 through chmod). Download method is set to Public.

Any ideas?

rj.seward’s picture

I found that the above error was being kicked out by a call to a function, file_save_upload() in a custom module. This function takes three parameters, one of which is the destination directory. I had specified a directory /home/uploads/ and since Drupal requires any writes to be within its own files/ directory, the error as above was being returned.

Here is the offending line of code before:
$end_file = file_save_upload($source, $dest = '/home/uploads/', $replace = FILE_EXISTS_RENAME);

and after:
$end_file = file_save_upload($source, "./", FILE_EXISTS_RENAME);

Now the problem appears to have been fixed.

Madness’s picture

I am having the exact same issue as you, so I was wondering if you had any luck finding a solution yet. Does anyone have any idea about how to fix this? The files go up, but they won't come down.

timmillwood’s picture

No luck yet, i just have to keep going in and editing the permissions after upload

It wouldn't have anything to do with the 'Download Method' in the 'File System' Settings. (Nope!)

Millwood Online http://www.millwoodonline.co.uk

Madness’s picture

I fixed my issue. I had to go in and edit the .htaccess file.

it seems that

Option...

thing does work for me for some reason, so i put a # before the Option, to make it look like

#Option

you can try that. but to go in each time, that would take a lot of time and effort.

btw, are you gonna change the favicon on your site?

timmillwood’s picture

Ok i dont really know what you mean about "Option" in.htaccess but i guess it will be clear when I have a look.

I don't know what to change my favicon to?

Millwood Online http://www.millwoodonline.co.uk

Danny_Joris’s picture

It looks like i have the same problem. What do you mean with option? The only 2 times 'option' appears in my .htaccess file is this snippet from line 10 to 14:

# Don't show directory listings for URLs which map to a directory.
Options -Indexes

# Follow symbolic links in this directory.
Options +FollowSymLinks

I still didn't find a sollution but I explained my problem here: http://drupal.org/node/476698

radu_pantelica’s picture

Short fix, followed by longer explanation:

Go to /admin/settings/file-system , set Download Method to "Private - files are transferred by Drupal", save the settings, and see if you are now able to access the uploaded files.

The longer explanation:

Depending on the setup of the web server, uploaded files will be saved with permissions 644, or 600, or maybe something else. Permissions 644 allow ALL server users to read the files, permissions 600 allow only the user that saved the files to read them.

The thing is - the user that "owns" the files (the one that saves them to disk) is a special one, used only by the web server program to do its work. It's not the account you use to administrate the web site - to login to cpanel or FTP. Because of this, sometimes even when you FTP to the site as admin, you cannot remove the uploaded files.

In my case, the files are saved with permissions 600, AND the user that owns them is not the same user Apache uses. So, the web server program cannot read them. I'm assuming my web hosting company uses different users for PHP processes and Apache processes, and the uploaded files are owned by the PHP user. For me, the simplest solution was to use PHP to read the files back to the user, by setting the download method to "Private - files are transferred by Drupal" in the admin page "/admin/settings/file-system".

Hope this helps.

digitalclover’s picture

First off, I want to thank you for showing us the fix for changing the download method to fix this problem. Unfortunately, I had to switch it back due to issues that involved CCK and Views.

When the Download Method is set to "Private - files are transferred by Drupal", images start behaving strangely when they are being displayed through a View block. It was never able to figure out the logic of the bug because it had so many random variables depending on what page, View, browser, and image file you were trying to display. When I turned the Download Method back to "Public" all of the bugs went away, but I'm now stuck with this original issue.

Is there by chance any other work around?