By XGI-Wrath on

Hi All...

I've spent a couple of weeks trying to get help by submitting a case. No joy. The thread can be viewed here: http://drupal.org/node/175973

I'm hoping someone here will have some experience with resolving this issue.

The symptoms are:

  • After (successfully?) attaching files (I've tried both image and text file), and submitting a page (or forum, message or whatever), clicking on the link that appears in the new node, the access denied error is displayed.
  • When adding an image node on image to a gallery, there's no thumbnail, preview, or original to view. But no error messages for the viewer.
  • In either case, the attempt to view the files results in an "access denied" entry in the log.
  • The files are indeed being uploaded. The text files are placed in the /public_html/files folder (drupal is installed in public_html), and images are uploaded to both /public_html/files and /public_html/files/images (thumbnail and preview versions are included in the images folder as well.)

Things I've checked so far and/or have (hopefully) eliminated as a cause:

  • Filesystem level permissions (have tried 664, 774, 775 and 777 on the files and folders.
  • The thumbnail/preview phenomena discussed here: http://drupal.org/node/170659 and here: http://drupal.org/node/175973. I've uploaded images that were larger than either the thumbnail or preview resulting in the same behavior. And, I'm pretty sure text files aren't affected by that particular issue. But I'm new to Drupal, and could be mistaken.
  • I've tried changing from a private download type to public.
  • I've checked, double-checked, and triple checked the Access Control settings Image, and Upload modules.
  • Tried allowing folder browsing by changing the "Options -Indexes" option in .htaccess to "Options +Indexes".
  • (Unsuccessfully) Attempted tried to configure "Clean URLs" using the many methods listed in handbook here: http://drupal.org/node/15365 as well as many of the methods described on the threads linking from it. (I believe I'm going to have to have my host providers cooperation.)

In case you're wondering why the heck I would mess with Clean URLs... At one point during my troubleshooting procedure, from one of the links as displayed on one of the pages the had an attachment, I happened to paste it into the address field on my browser, I cleaned it up by removing the "?q=node" and Viola'! There was the file! Now the problem is that I can't duplicate it. I may have done that during one of my Clean URL attempts.

So, I guess that's it. Or at leas All I can remember at the moment. If you're interested in seeing the support thread as to not duplicate efforts, you can read it here: http://drupal.org/node/175973 For the sake of completeness I'll also include another thread that I participated in long enough to rule out that particular cause. That thread is here: http://drupal.org/node/160671

Here is our system info:

Drupal
Version	5.2
Configuration file	sites/default/settings.php
Cron	Last run 7 hours 19 min ago

Web server
Type	Apache
Version	1.3.37
Operating system	Linux
PHP interface	cgi
URL	http://dfbrigade.org

PHP
Version	4.4.7
Magic quotes GPC	On
Magic quotes runtime	Off
Memory limit	40M
Register globals	On
Safe mode	Off
Session cache limiter	none
Session cookie domain	.dfbrigade.org
Session name	SESSbe0121b73baef910505c323ec95d184c
Session save handler	user
Upload max filesize	10M
Extensions
CURL version	l
GD version	bundled (2.0.28 compatible)
FreeType support	Enabled
JPG support	Enabled
PNG support	Enabled
Multibyte support	Enabled
XML support	Enabled
Zip support	Disabled
Zlib support	Enabled


Database
Host	localhost
Name	brigade_brigdrupal01
Type	MySQL
Version	4.1.22
Charset	utf8
Collation	utf8_general_ci
Permissions
Create temporary tables	Disallowed
Lock tables	Disallowed
Table prefix

Thanks in advance for any help that anyone can lend.
-=w=-

⋅ Categories: Drupal 4.5.x or older

Comments

cog.rusty’s picture

cog.rusty commented

Check the file paths in your 'files' table in the database (hmm... you say you are using a version older than 4.5.x? Was that table even called 'files' at the time?).

Are the paths in the table like 'system/files' or just 'files'? Compare with the paths in your links in the content. Switching between "private" and "public" could have caused the problem, because the upload link paths and the database paths become wrong.

In any case, the images should be always visible when you access them using 'files' and not 'system/files', bypassing the "private" system, if you have them stored above your web root.

On the other hand, when the file system setting is "private", the user also needs permission to view the node where the file was uploaded, and not only permission to view uploaded files. This is controlled by the 'files' table's entries. But if you experience this as user #1, then it was never a permission problem.

XGI-Wrath’s picture

XGI-Wrath commented

Hey, thanks for the reply.

When you say that we're running a version that is older than 4.5.x, what do you mean? Are you referring to my PHP or SQL version? Besides the GD version, those are the only things listed that display a version number. I guess I'm having trouble with your comment about table names. My Drupal version is 5.2 and the installation is only a little under four weeks old. Or are your referring to one of the modules? Sorry, trying to understand this one.

The second paragraph I understand. The file system path is set to "files", and the temporary directory is set to "/tmp". Until yesterday our download method has always been set to private. We've had this issue since installing Drupal about four weeks ago. Knowing that it would likely screw up any existing links, I only temporarily set it to public yesterday in a last ditch effort to locate the source of this problem. I figured, what the heck... They're not working anyway. If I break them further, no one will notice. lol

In your third paragraph you mention bypassing the the private system. I think maybe the .htaccess file in the images folder prevents that, even when directory browsing is enabled via the .htaccess file in the system root. I'd have to test that to be sure though. I do one thing though: Even with directory browsing is enabled via the .htaccess file in the system root, I still can't access those files in the files folder directly, and I can't browse it either. I can however browse other sub-folders off the root.

And yes, I agree, the #1 account is experiencing the same symptoms. So it's not a permissions problem.
Still haven't figured it out. :-( But thanks for the help. As I'm finishing this post I'm playing with the directory structure and the file system settings. (So I may break my examples above. Sorry.)
But something you said about the path to the files as compared to the links that are generated. It just doesn't seem to jibe. I'll post again later after I play with it some more. But lunch is over for now. :-(

LTC.Wrath-BRIG-XO
http://dfbrigade.org
wrath|at|dfbrigade.org

cog.rusty’s picture

cog.rusty commented

When you say that we're running a version that is older than 4.5.x, what do you mean?this one.

Nothing profound. You have tagged this forum topic as "Drupal 4.5.x or older" on the top. Obviously a mistake.

In your third paragraph you mention bypassing the the private system. I think maybe the .htaccess file in the images folder prevents that, even when [...] Example2: You cannot browse the "files" folder even though it is at the same level as "test". http://dfbrigade.org/files/Linux_Pro2C_Professional_Operating_System.jpg

I am surprised. This kind of protection just does not happen in any other Drupal installation I have seen. The default Drupal .htaccess file just leaves real files alone, and the small .htaccess in 'files' does not prevent viewing the files by filename. I would have bet that the only way for this to happen is to make the files unreadable by the server or missing.

Probably Drupal's .htaccess file has been modified and the line RewriteCond %{REQUEST_FILENAME} !-f near the end has been removed.

But something you said about the path to the files as compared to the links that are generated. It just doesn't seem to jibe.

What I mean is:

1. Browse to a few non-appearing files, right click, and see what is the path where it is trying to go. On a couple that I tried the path seems to be ?q=system/files/filename or ?q=system/files/files/filename. This path is either in the image links in the content or produced by some filter. To display such an image, only the "private" file system can make those virtual paths work.

2. Compare those file paths with the paths found in your database, in the files table. (Not very important at this point, because those are used mostly for access control with the "view uploaded files" permission and with other node based access methods)

XGI-Wrath’s picture

XGI-Wrath commented

Hello again Rusty, and thanks for taking the time to help me sort this thing out.

I see what you mean now about the version. Being a dyslexic, I often do stuff like that. And I'm joking. I really am dyslexic, and AD/HD. LOL I don that fairly often. My version installation is the exact opposite of the oldest. lol Sorry for the confusion. I wonder If I can change that. ???

I get what you are saying about the .htaccess file. I'll check that out next chance I get to work on it.

Those links... Yeah, they don't seem right. You said check them out and I did. That's what I meant about them not jibing. They just didn't seem right. I'll look in the database too, and let you know.

There's something else that doesn't seem right to me, but I don't know how to express it. It has to do with the directions on the admin\file system page not matching the directory structure. I'll try a bit later when I have more time. (I'm still at work and should get back to it. shhhh)

Thanks again for your help. I had gotten pretty disillusioned there for a while. This is refreshing. :-)

LTC.Wrath-BRIG-XO
http://dfbrigade.org
wrath|at|dfbrigade.org

XGI-Wrath’s picture

XGI-Wrath commented

Hey there Rusty. I don't know if you're still out there. I've been out of town and haven't had much time to work this issue.

1. Browse to a few non-appearing files, right click, and see what is the path where it is trying to go. On a couple that I tried the path seems to be ?q=system/files/filename or system/files/files/filename. This path is either in the image links in the content or produced by some filter. To display such an image, only the "private" file system can make those virtual paths work.

2. Compare those file paths with the paths found in your database, in the files table. (Not very important at this point, because those are used mostly for access control with the "view uploaded files" permission and with other node based access methods)

OK... I finally made time to check out what you were saying.
The paths in the data base look fine. I can take any one of them and append it to my host name and it works perfectly every time. Of course none of those entries contains the ?q=system/files portion. I wonder what the heck is generating those links? Any ideas?

LTC.Wrath-BRIG-XO
http://dfbrigade.org
wrath|at|dfbrigade.org

cog.rusty’s picture

cog.rusty commented

Normally the "system/files/filename" virtual paths (with or without ?q=, depending on your Clean URL setting) are created when using the "Private download method" and you upload a file.

While using the "Private" download method, Drupal gives you an URL of that kind to use in the content.

From what I can see in the files table in the database, that virtual path is not stored in the files table. The real path is stored. Then:
- While using the "Private" method, the virtual file paths found in the content are automatically bringing the file from the real path.
- When using the "Public" method, the virtual file paths found in the content just stop working.

So, it is possible that you uploaded the files while using the "Private" method, then you (or some module) used the suggested virtual path to place those files/images in the content, and now (with the download method set to "Public") you have virtual paths in the content which don't work any more and need to be replaced with real paths.

XGI-Wrath’s picture

XGI-Wrath commented

Hmmm... OK. I think I'm starting to understand how this works. Thanks for the "class". LOL

The problem is that the download method isn't set to public. It's set to private. When I set the site up, I set it up as private. But we couldn't see any images uploaded to the image gallery. That's when I tried just the basic attachments. They didn't work either. Eventually I got around to temporarily changing the download type to public, and file permissions for one of the files to 777. No Joy. I then try attaching a single file to a single node with the download method set to public. When that didn't make a difference, I immediately returned to private mode. So this is pretty weird huh? Where to now?

Here's a link to node with an attachment that I created just a few minutes ago: http://dfbrigade.org/?q=node/185

By the way, I wanted to say thanks a million for sticking with me on this. I used to run a PHPNuke site and am now in love with Drupal. This one issue is really being pesky though!

LTC.Wrath-BRIG-XO
http://dfbrigade.org
wrath|at|dfbrigade.org

cog.rusty’s picture

cog.rusty commented

From what I can see, your attached file can be accessed directly using its real path:
http://dfbrigade.org/files/Spammers_IP_List.txt

This means that there is no file permissions problem, only a Drupal problem, because when you use the suggested link
http://dfbrigade.org/?q=system/files/Spammers_IP_List.txt
then Drupal gives you an "Access denied" page

I guess you have set your download method to "Private" and your files directory to "files" in the /admin/settings/file-system page.

Since I can see the node where the file was attached, but not the file itself (at least when using the Drupal path), do anonymous users have "view uploaded files" permissions in the /admin/user/access page?

Also take a look at the /admin/content/node-settings page and if you see a "Rebuild permissions" button there try it.

XGI-Wrath’s picture

XGI-Wrath commented

Anonymous users do have permission to view uploaded files. I hadn't bothered to test access to see if that was going to satisfy our security requirements. I figured it was pointless since there's obviously some issue related to access that needs to be resolved.

I tried the node rebuild function. No joy. I tested an existing node and I also created another. Neither worked. It's so perplexing that I'm crying and laughing at the same time. OK not really, but it is both funny and frustrating. :-) What now Sensei?

LTC.Wrath-BRIG-XO
http://dfbrigade.org
wrath|at|dfbrigade.org

Anonymous’s picture

Anonymous (not verified) commented

Brig, I was experiencing the same issue with the attachment file paths also reflecting the same (/system was being inserted in the file URL).

I recalled that originally, in my case, all the files had been uploaded/attached while the file system download method was set to "Public". Then I added a new module (download count) and realized the counts couldn't be tracked unless I changed the download method to "Private". I made the change and all appeared fine but I didn't really test it (shame on me). Then I encountered this problem days later (attached files could be viewed by all the correct users but download attempts resulted in a "page not found" error, even for user 1). I switched the file system download method back to "Public" and everything is working again.

I realize you may be experiencing something different but this is how I fixed my issue. Wish there was something that could be done to "find" uploaded files attached to existing nodes, but it seems to me the only work-around is to re-upload/re-attach each item if the download method is changed. :-(

XGI-Wrath’s picture

XGI-Wrath commented

Thanks zacamjo.

You're correct in that my problem is a little different. Our site started out as Private and we observed these symptoms without ever having changed our type to Public.

LTC.Wrath-BRIG-XO
http://dfbrigade.org
wrath|at|dfbrigade.org

pmcvoy’s picture

pmcvoy commented

Hi Brig,

I'm having a similar problem except....

I do not want anonymous users users to be able to access uploaded non image files (we sell publication files on the site), but I do want them to see uploaded images. Have you found an answer to your problem?

Thanks,

pmcvoy

Paco_flores’s picture

Paco_flores commented

I'm having a similar problem.
Please, any solution?

dimiduj’s picture

dimiduj commented

I dont know if mine is similar but
I set download to private
Permission to view download for auth user is on and I get a Acces denied when I try to download a file (except for uid=1 => i can download the file )...

I use drupal 5.5
Firefox

I have iddentified 2 source of problem in my case :

1) the system in the URL => remove it from your browser

2)It seems that the problem comes from the + (inserted in the URL when you have space in yours name's file ) they should be %20
=> replace + by %20

Now you should be able to access your document ... (tested in Firefox and Safari)
the stranger is that when I have uid=1 I dont need to do this two steps to get my file ....

Any ideas to solve the bug ...?
Any help will be really appreciate

Maybe that a fast/crapy fix will be to correct URL in the template engine ( with php template ) but i'm not sure of that and not an expert in phptemplate ... anu help ??

thx ...