By iain on

I'm not a tecchie, so please bear with me.

I'm installing 5.1 on behalf of a charity, having successfully test driven it on a small test Linux site. In the last few days, I've tried to install the same set-up on a Unix server run by storminternet.co.uk who provide advantageous rates for registered charities.

The upload and database initialisation seemed to go ok, but I couldn't get the install to start - 'internal server error' was the message. The Storm guys suggested that .htaccess was the problem, as their set-up didn't support rewriting permissions, and recommended I delete .htaccess. I did this and was able to fire up Drupal. However, once I copied in some html from previously tested pages, any references to images or download documents resident in files/ failed to resolve.

Next step was to use Chmod to set the permissions for files/ to eee - I could now see its contents using FTP, but still no images displayed or downloads possible. The Storm guys are friendly and trying to help but they don't know Drupal.

Anybody got ideas? Do I need to comment out any parts of .htaccess to make the thing work (if so, how do I find out which parts)? Do I need to get any technical information from site logs to get to the root of the problem? I don't know Unix, so any obvious dos and don'ts I should attend to?

⋅ Categories: Drupal 5.x

Comments

styro’s picture

styro commented

It sounds like you set your development/test site up with clean urls, but that you unfortunately can't use them in your production environment.

It also sounds like you are now using private downloads? Is that correct? I say that because the paths for public downloads shouldn't be affected by clean vs standard url changes as they are outside Drupal (ie unaffected by url rewriting). Unless you want to recreate all the uploaded files and images, I'd recommend using the same public vs private setting on your production setting that you used for testing.

Converting from a public download with clean urls to a private download with standard urls: <img src="/files/image1.jpg" /> becomes <img src="/index.php?q=system/files/image1.jpg" /> This is from memory - it assumes Drupal is installed in the web root not in a subdirectory (and I haven't tested it)

But your file entries in the database won't be correct if you change your public/private downloads setting. You'll need to recreate them all if you aren't comfortable wrangling the data in the database.

--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal

iain’s picture

iain commented

Styro

Thanks for that.

I looked at my production Drupal settings (Unix host), and for Clean URLs, I am currently disabled with the radio buttons greyed out (the clean URL test gives page not found). Under File System, my setting is public.

I then went back to the test system (Linux host), and for Clean URLs, I am disabled but the radio buttons are available as the test worked when run. Under File System, my setting is public, but there is a warning on the page:
Security warning: Couldn't write .htaccess file. Please create a .htaccess file in your files directory which contains the following lines:
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +FollowSymLinks
I haven't created the .htaccess file on the test system, but all my images/downloads display/load correctly.

So, I think I need to get someone to change server settings on the production Unix system? This is the area where the host support guys are saying that they don't allow software to change permissions. Is there some way out of this impasse?

kingofswing’s picture

kingofswing commented

hi,iain,this morning,I encountered the same problem,here is what I found and finally resolve this problem, because I'm from china,pls forgive for my poor english :-)
I also installed drupal 5.1 on my centos4.4 machine, at first,I couldn't open the install page until I commented out all the lines of the .htaccess in the root directory of the drupal site. (at first I may want to comment out some lines of OPTIONS xxxxxx,but it didn't work, then commented out all lines of .htaccess , the install homepage displayed at last, anyway , if .htaccess didn't play much role, so in order to make it run , why not #out all lines of the .htaccess of drupal site?)

I tried to apply a new account, no problems, but after uploaded a 80x68 jpg file to the site under my account, it didn't display the image as I wished, right-click , the image URL is okay, but the size is 135x35 pixels(it seems to be not equal to the size of my uploaded image), then I check the error log of my centos's httpd.conf vhost.conf, in vhost.conf, in error.log I found :
[client 60.190.160.83] /var/www/web15/web/files/.htaccess: Options not allowed here, referer: http://www.mydomain.com/?q=user/4
(my normal account ID is no.4,I guess), so I turn to check the .htaccess under "files", it's content :

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +FollowSymLinks

I'm not familar with Apache option settings, then mv .htaccess to .htaccess.bak, re-enter my normal account , found it can dispaly my logo image !

so you maybe should goto /yourwebroot/files/ to check if a .htaccess exist there, try backup it to another name,then try again. hope it will works!

Kingofswing

iain’s picture

iain commented

Thanks for your reply! See also my reply to styro. I think the answer will be some combination of site configuration options inside Drupal plus whatever server security settings the host supplier allows. I tried renaming root/files/.htaccess to another name last night, but Drupal immediately wrote another .htaccess to the directory so I still have the same problem!

kingofswing’s picture

kingofswing commented

Having seen your post, I login using my normal account, (my variable is file & file/tmp, which stands for the FILE system variables), under "files" directoy of my web root, as I mentioned in my previous post I mv .htaccess to .htaccess-bak. there are 2 sub-directory under "files"directory, one is 'tmp', the other is 'pictures' (which I input in "USER Settings" section, and drupal create it itself), when we upload a 85x85 image to the site,drupal first create a temp file under "files/tmp/", named "tmp_XxxXXX", then it will check if It has permission to move&rename it to files/pictures subdirectory, in order to test if drupal re-create the .htaccess file under "files" directory , I login in my normal account, delete the image, (check it worked , picture-4.jpg was deleted in "files/pictures" directory), and then reupload the same image, it also worked, and found drupal didn't create .htaccess file under "files" directory(as you see, I mved .htaccess to .htaccess-bak )

iain’s picture

iain commented

After running some more tests this weekend, I still can't get this set-up to work, and I could use some quick assistance - my project is starting to slip its dates.

To recap, I installed Drupal 5.1 on a Unix/Apache host system, a technology I don't know, and where the host doesn't like changes to permissions. Deleting .htaccess from the root directory got me past the first set of problems, but I am stuck with references from my content pages to images and download files not being resolved.

The problem seems to be Drupal writing .htaccess to the files folder. The content of this doc is:
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +FollowSymLinks

My settings are clean URLs disabled (and I can't run the test); file system path 'files'; temporary directory 'tmp'; download method 'private' (it was public, but I will need access controls later). My html references are of the form src="files/image.gif"

I tried deleting and renaming .htaccess from the files folder and was briefly able to see all my images before Drupal wrote another version of it. I tried commenting out the lines above, but no joy. I tried re-uploading all my files, but also no joy.

I don't think I'll be able to persuade the hosts to change their set-up, so is there any way I can configure or patch Drupal to let me access the docs I need?

styro’s picture

styro commented

by focussing on .htaccess files and Apache permissions. I don't think that's your problem. Drupal works without clean urls, .htaccess etc.

I think your main issue is that you've switched from public to private downloads and from clean urls to standard ones. And these changes have invalidated your internal links.

I see a bunch of problems / inconsistancies in you settings so far:

* src="files/image.gif" should really be src="/files/image.gif". If that HTML was (for example) on a url of /node/57 then your browser would be looking for it at: /node/57/files/image.gif. Your 404 error logs probably tell you something like that.

* With private downloads your files directory should be outside your browsable web root or protected from browsers in some other way. Otherwise you may as well just use public downloads. With public downloads it is Apache that serves the files directly - Drupal has no knowledge of the downloads. With private downloads, the files are somewhere Apache can't get them and Drupal itself opens the files from the filesystem and serves them up. Access control for public downloads is done through Apache, while access control for private downloads is done through Drupal. Public downloads are less resource intensive for this reason.

* With private downloads from a directory outside the web root, any .htaccess file there is irrelevant anyway as Apache won't be reading it.

* once your files are in a private downloads directory outside your web root paths like src="/files/image.gif" won't work anymore. You'll need to get the files via the Drupal system module - eg: src="/system/files/image.gif".

* And because you don't have clean urls anymore, private download paths like src="/system/files/image.gif" won't work either. You'll need to write them in the form: src="/?q=system/files/image.gif" or src="/index.php?q=system/files/image.gif"

Addressing those points should hopefully get you links working.

--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal

iain’s picture

iain commented

Styro

Thanks again for taking the time to help. I think I may now have cracked the problem, and the solution is closer to what kingofswing was trying to tell me a few days back.

I decided that the cleanest way to proceed was to use public downloads after reading a number of forum threads about private - I don't need access controls just yet, and there may be some modules which can help me later on. In the meantime, I will need to let all site users have access to images and promotional material.

So, my strategy reverted to uploading images and docs using ftp without involving Drupal. The clincher was to rename the file path in my File System settings - instead of 'files' I used 'filesxyz' so Drupal is now happily writing its .htaccess files there, while I let http access my images and docs from 'files/subfolders/etc' without problem.

Doing it this way means that references like src="files/image.gif" or href="files/word.doc" on content pages now work fine, as they had done on my test system. If I'm using internal references to jump from one content page to another, then I need href="?q=node/23" or similar to make the link work.

I hope I'm not contravening any rules or creating longer-term problems by doing this. It is a good feeling to see these pages come to life!

mauryg’s picture

mauryg commented

iain,

I wish I had seen this thread 8 hours ago. I have a new install of 5.1 and input some pages with embedded pictures. They were stored in root/files/images. When I viewed the page, there were no pictures. I copied the whole site to my WAMP server on my desktop and imported the SQL database. It ran perfectly, with clean URLs and all pictures displayed. I spent an hour on the phone with the tech at my hosting provider trying all kinds of path designations for the picture files, still no success. I even wrote a simple HTML page to use an image in the files/images folder. Nothing wouild work unless I moved the picture file OUTSIDE the FILES folder. After I hung up I decided to disable the .htaccess file in the files folder by renaming it .htaccessbak. BINGO! All the pictures were there. I tried commenting out each line of the .htaccess file separately, but no luck. All three lines had to be removed for the images to load. BTW, I use the .htaccess file in the root folder for rewrites and clean URLs work fine on the shared host. Go figure. The KingofSwing was right.
I know the .htaccess file in the files folder is there for security against XSS attacks (SAC_2006_006, http://drupal.org/node/66763), so if I can do without public file uploads, I may just move the images file outside of the httpdocs folder.