No access to public folder on RoR install


I set up a Ruby on Rails site using Capistrano. After much blood, sweat, and tears, I have gotten the website almost entirely up and running. The rails code properly generates the web page content. The only problem is that anything that is coming from the /public directory isn’t coming through. This means stylesheets, javascripts, and images, which make the site virtually useless. If I look in the rails production.log, I get the following error (one for each stylesheet, javascript, etc the page is trying to load):

ActionController::RoutingError (No route matches “/javascripts/application.js” with {:method=>:get}):

According to what I have been told, the responsibility only gets handed to ruby after the web server can’t get to or access the file in the public directory. I have already checked the permissions on /public and the underlying files and folders (755), and in my domain settings the web directory is home/username/domain_name/current/public.

Is there something else I should check? I asked dreamhost support to look at my web server configuration, and they just told me it must be my application. I do not have this problem on my dev server, or on another production server I previously deployed to, so it would be strange if the application itself was the issue. I can’t do much without this, so any help would be greatly appreciated.


Rereading this, I realize that I made it too complicated. In reality, the rails install shouldn’t even be a factor. Let say I have an image file in /home/username/ want someone to be able to see it when they go to The way the rules are written, the request doesn’t even go to rails unless the server can’t find it first. The web server finds my .htaccess file in the proper folder, so it seems that the issue might be in my .htaccess file… right? I’m really at a loss here. Here’s my htaccess file, most of it was autogenerated by rails, I don’t understand the details of a lot of it:

AddHandler fastcgi-script .fcgi
AddHandler cgi-script .cgi
Options +FollowSymLinks +ExecCGI

RewriteRule ^(.)$ dispatch.fcgi [QSA,L]
RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteCond %{SCRIPT_FILENAME} !^(.+).(gif|jpg|css|js|swf)$
RewriteRule ^.
$ /system/maintenance.html [L]

RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

ErrorDocument 500 “

Application error

Rails application failed to start properly”


Being lazy, I’d log in to shell and make a symbolic link (alias) for the images directory:

cd ~/
ln -s current/public/images .

Now you’ll have a directory that’s shows what’s in current/public/images



I played around with symbolic links earlier, but I couldn’t get the desired result. I tried several variations, but none of them really work. Nothing I symlink to the ~/ directory seems to do any good.

In theory, I have the web directory set up as via the panel, wouldn’t that mean that should point to ~/ anyway?


I wouldn’t symlink to a ~. Make it a relative path. So it won’t matter what your web directory really is.

When you made the symlink, what happened?



Well, I see the working symlink in the ~/ directory (as in, ~/, but it didn’t seem to have any effect. I tried restarting the server, but I’m still not able to access anything that is in the public folder. I tried doing it as a relative path, using the command you provided.

Still no idea why this is happening.


Try to rename your .htaccess to .htaccess.sav and see if the symlink works. I know it’ll break your site, but at least it’ll narrow down what’s stopping it from working. If that’s the problem, then you can modify .htaccess to not rewrite if it’s calling /images



Excellent troubleshooting idea! I renamed .htaccess as you recommended, and I had instant access to the public folder, including /public/images, of course with a full directory listing served from apache. Obviously the issue lies with my .htaccess. I guess now I will have to go read up on mod_rewrite… I guess it had to happen eventually. If you see anything glaring in my .htaccess file, let me know. I’ll tackle it tomorrow, starting with removing one piece at a time to narrow it down.


Here’s a place to get you started:



I got it!

I commented out the first instance of RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]. It seemed out of place to me (before RewriteEngine On), and it is a duplicate of a line near the bottom of the file. Now my site works, and no error messages in my log files. I’m pretty sure I didn’t put that in myself (why would I? I don’t even know what it means). At least I can put off learning the nuances of .htaccess for at least another day.

Thanks for your help, I probably would not have found it if not for your suggestion.