Error 404 on uploaded files #348

Closed
chibani opened this Issue Jan 28, 2012 · 41 comments

Projects

None yet
Contributor
chibani commented Jan 28, 2012

When I attach a file to a note (on the Wall), everything is fine (I mean, no error).
But when I try to download the uploaded file, I get a 404 error ...

This issue occurs on v2.0 and v2.1 :(

I have the same error. The file takes ages to get uploaded without ever succeeding. And when I finally cancel the operation, I see there is an attachment to my note but I can't access it, 404 error.

Edit: and the log doesn't contain anything strange.

Contributor
chibani commented Jan 28, 2012

Here's the log :

Started GET "/hap_be/wall?last_id=11&=1327789337914" for 88.168.154.152 at 2012-01-28 23:22:23 +0100
Processing by ProjectsController#wall as JS
Parameters: {"last_id"=>"11", "
"=>"1327789337914", "id"=>"my_project"}
Rendered notes/_load.js.haml (4.4ms)
Rendered projects/wall.js.haml (5.5ms)
Completed 200 OK in 23ms (Views: 7.2ms | ActiveRecord: 2.7ms)

Started GET "/uploads/note/attachment/11/full_2.0a.zip" for 192.168.0.1 at 2012-01-28 23:22:25 +0100

ActionController::RoutingError (No route matches [GET] "/uploads/note/attachment/11/full_2.0a.zip"):

Contributor
chibani commented Jan 28, 2012

Also, my file is correctly uploaded, I can see it while browsing on my server :
/home/gitlabhq/gitlabhq/public/uploads/note/attachment/11/full_2.0a.zip

Same thing here :)

Contributor
chibani commented Jan 30, 2012

I've looked at the routes script (I don't know rails...)
And i've not seen any "upload" or "attachment" routing config... Am I wrong ?

Contributor
chibani commented Jan 31, 2012

Are we the only persons annoyed by this issue ?

I guess so, 'cause the demo app seems to work properly. Maybe some server side error just not thrown...

Contributor
chibani commented Jan 31, 2012

Haven't you got the same issue ?

I indeed have the same issue.

Contributor
chibani commented Feb 9, 2012

Still no one to tell us how we can fix this ? Can it be a distro problem ?

I still got this error on my own server, on which I did the install somehow wrong.

I just finished a new install onto our teamwork server at my office, I used this process: https://github.com/gitlabhq/gitlabhq_install

I can tell you that everything works fine with this instructions. I still don't know where the error comes from on some installations, but as I said, it's probably something misconfigured on the server.

Use this guide, it worked for me.

Contributor
chibani commented Feb 10, 2012

So, you're telling me I should reinstall gitlab (and all his required stuff) ? :/

I don't know, I just said that a fresh install following this workflow worked well.

Contributor
chibani commented Feb 10, 2012

Seems legit ;)
Thanks :p

The process at https://github.com/gitlabhq/gitlabhq_install doesn't use the stable branch. You can see this in "ubuntu_gitlab.sh". There is definitely an issue with uploaded files in the stable branch. We should bump this issue!

Contributor
chibani commented Feb 12, 2012

I think i'll have to move to the master :p

Contributor
chibani commented Feb 22, 2012

I've just updated to 2.2, and the issue is still here :/
Here's the log :

Started GET "/uploads/note/attachment/42/223652714_a859e1fb60_z.jpg" for 192.168.0.1 at 2012-02-22 20:34:50 +0100

ActionController::RoutingError (No route matches [GET] "/uploads/note/attachment/42/223652714_a859e1fb60_z.jpg"):
actionpack (3.2.1) lib/action_dispatch/middleware/debug_exceptions.rb:21:in call' actionpack (3.2.1) lib/action_dispatch/middleware/show_exceptions.rb:56:incall'
railties (3.2.1) lib/rails/rack/logger.rb:26:in call_app' railties (3.2.1) lib/rails/rack/logger.rb:16:incall'
actionpack (3.2.1) lib/action_dispatch/middleware/request_id.rb:22:in call' rack (1.4.1) lib/rack/methodoverride.rb:21:incall'
rack (1.4.1) lib/rack/runtime.rb:17:in call' rack (1.4.1) lib/rack/lock.rb:15:incall'
rack-cache (1.1) lib/rack/cache/context.rb:132:in forward' rack-cache (1.1) lib/rack/cache/context.rb:241:infetch'
rack-cache (1.1) lib/rack/cache/context.rb:181:in lookup' rack-cache (1.1) lib/rack/cache/context.rb:65:incall!'
rack-cache (1.1) lib/rack/cache/context.rb:50:in call' railties (3.2.1) lib/rails/engine.rb:479:incall'
railties (3.2.1) lib/rails/application.rb:220:in call' rack (1.4.1) lib/rack/content_length.rb:14:incall'
thin (1.3.1) lib/thin/connection.rb:80:in block in pre_process' thin (1.3.1) lib/thin/connection.rb:78:incatch'
thin (1.3.1) lib/thin/connection.rb:78:in pre_process' thin (1.3.1) lib/thin/connection.rb:53:inprocess'
thin (1.3.1) lib/thin/connection.rb:38:in receive_data' eventmachine (0.12.10) lib/eventmachine.rb:256:inrun_machine'
eventmachine (0.12.10) lib/eventmachine.rb:256:in run' thin (1.3.1) lib/thin/backends/base.rb:61:instart'
thin (1.3.1) lib/thin/server.rb:159:in start' rack (1.4.1) lib/rack/handler/thin.rb:13:inrun'
rack (1.4.1) lib/rack/server.rb:265:in start' railties (3.2.1) lib/rails/commands/server.rb:70:instart'
railties (3.2.1) lib/rails/commands.rb:55:in block in <top (required)>' railties (3.2.1) lib/rails/commands.rb:50:intap'
railties (3.2.1) lib/rails/commands.rb:50:in <top (required)>' script/rails:6:inrequire'
script/rails:6:in `

'

Owner
randx commented Feb 22, 2012

Cant reproduce. I tried for apache + passenger and thin

Contributor
chibani commented Feb 22, 2012

Sorry, I don't understand :/

Owner
randx commented Feb 22, 2012

What web server do you use?

Contributor
chibani commented Feb 22, 2012

thin 1.3.1

Owner
randx commented Feb 22, 2012

I need some information from you:

  1. File path
  2. Full url
  3. 100% guarantee that file exists
Contributor
chibani commented Feb 22, 2012
  1. /home/gitlabhq/gitlabhq/public/uploads/note/attachment/43/3903075273_b28a194c86_z.jpg
  2. http://xxxxxx:3000/uploads/note/attachment/43/3903075273_b28a194c86_z.jpg
  3. -rw-r--r-- 1 gitlabhq gitlabhq 140426 2012-02-22 21:04 public/uploads/note/attachment/43/3903075273_b28a194c86_z.jpg

Thanks :)

bzick commented Feb 28, 2012

+1 same issue

bzick commented Feb 28, 2012

GitLab 2.2 (tag)

http://****/uploads/note/attachment/14/Personal_Trollface_HD.png - 404

ls -la /data/www/gitlabhq/public/uploads/note/attachment/14/Personal_Trollface_HD.png
-rw-r--r-- 1 gitlabhq gitlabhq 18860 2012-02-28 18:03 /data/www/gitlabhq/public/uploads/note/attachment/14/Personal_Trollface_HD.png

thin 1.3.1 codename Triple Espresso
Ubuntu 11.10

Log fragment:

 Started GET "/uploads/note/attachment/14/Personal_Trollface_HD.png" for ******* at 2012-02-28 18:03:54 +0400

 ActionController::RoutingError (No route matches [GET] "/uploads/note/attachment/14/Personal_Trollface_HD.png"):
Contributor
chibani commented Mar 9, 2012

Sorry to ask once again, but I really really need this to work ...

Me too have same issue. I did fresh install of gitlab just now.

I am getting this message "404 The page you were looking for doesn't exist.
You may have mistyped the address or the page may have moved.
"

The image path in browser: http://0.0.0.0:3000/uploads/note/attachment/1/Greenturtle_logo.png

The image path in filesystem:
gitlabhq@gtt-ubuntu:~/gitlabhq$ ls -lh public/uploads/note/attachment/1/Greenturtle_logo.png
-rw-r--r-- 1 gitlabhq gitlabhq 28K 2012-03-09 13:59 public/uploads/note/attachment/1/Greenturtle_logo.png

Log output:

Started GET "/uploads/note/attachment/1/Greenturtle_logo.png" for 127.0.0.1 at 2012-03-09 14:49:05 +0530

ActionController::RoutingError (No route matches [GET] "/uploads/note/attachment/1/Greenturtle_logo.png"):
actionpack (3.2.1) lib/action_dispatch/middleware/debug_exceptions.rb:21:in call' actionpack (3.2.1) lib/action_dispatch/middleware/show_exceptions.rb:56:incall'
railties (3.2.1) lib/rails/rack/logger.rb:26:in call_app' railties (3.2.1) lib/rails/rack/logger.rb:16:incall'
actionpack (3.2.1) lib/action_dispatch/middleware/request_id.rb:22:in call' rack (1.4.1) lib/rack/methodoverride.rb:21:incall'
rack (1.4.1) lib/rack/runtime.rb:17:in call' rack (1.4.1) lib/rack/lock.rb:15:incall'
rack-cache (1.1) lib/rack/cache/context.rb:132:in forward' rack-cache (1.1) lib/rack/cache/context.rb:241:infetch'
rack-cache (1.1) lib/rack/cache/context.rb:181:in lookup' rack-cache (1.1) lib/rack/cache/context.rb:65:incall!'
rack-cache (1.1) lib/rack/cache/context.rb:50:in call' railties (3.2.1) lib/rails/engine.rb:479:incall'
railties (3.2.1) lib/rails/application.rb:220:in call' rack (1.4.1) lib/rack/content_length.rb:14:incall'
railties (3.2.1) lib/rails/rack/log_tailer.rb:14:in call' thin (1.3.1) lib/thin/connection.rb:80:inblock in pre_process'
thin (1.3.1) lib/thin/connection.rb:78:in catch' thin (1.3.1) lib/thin/connection.rb:78:inpre_process'
thin (1.3.1) lib/thin/connection.rb:53:in process' thin (1.3.1) lib/thin/connection.rb:38:inreceive_data'
eventmachine (0.12.10) lib/eventmachine.rb:256:in run_machine' eventmachine (0.12.10) lib/eventmachine.rb:256:inrun'
thin (1.3.1) lib/thin/backends/base.rb:61:in start' thin (1.3.1) lib/thin/server.rb:159:instart'
rack (1.4.1) lib/rack/handler/thin.rb:13:in run' rack (1.4.1) lib/rack/server.rb:265:instart'
railties (3.2.1) lib/rails/commands/server.rb:70:in start' railties (3.2.1) lib/rails/commands.rb:55:inblock in <top (required)>'
railties (3.2.1) lib/rails/commands.rb:50:in tap' railties (3.2.1) lib/rails/commands.rb:50:in<top (required)>'
script/rails:6:in require' script/rails:6:in

'

Contributor
ariejan commented Apr 10, 2012

This is not directly an issue by Gitlab, but with the configuration for your front-end server. If you're using Nginx, you should tell nginx to serve statis files (skipping the proxy to the Rails app):

location ~ ^/(uploads)/  {
  root /home/deployer/apps/gitlabhq/current/public;
  expires max;
  add_header Cache-Control public;
  break;
}
Contributor
ariejan commented Apr 10, 2012

Just to be clear:

Rails (e.g. gitlab, which you run with thin, webrick or unicorn) is configured (as it should be!) to not serve static content from public in production. It's your front-end server's job to serve static assets.

If you get an error in gitlab's (rails') log then your front-end server is not configured properly to serve static files. My previous comment shows how to configure nginx to check if a static files can be served before passing the request to Gitlab.

Contributor
chibani commented Apr 10, 2012

Ok. Got it... (almost)
Now, where can I says Thin to route the uploaded files the right way ? :p

Contributor
ariejan commented Apr 10, 2012

@chibani if thin is your front-end server, you're doing it wrong. Thin is great to run your Rails app, but for serving static files you'll need apache or nginx.

Contributor
chibani commented Apr 10, 2012

I just use gitlabhq the "default way"...
I'll try setting it up with nginx in front.

Thanks Ariejan,

This clears my doubt. I was not aware of why front end server
configuration (Nginx/Apache) is needed.

Thanks,
Kiran Patil.

On 4/10/12, Ariejan de Vroom
reply@reply.github.com
wrote:

Just to be clear:

Rails (e.g. gitlab, which you run with thin, webrick or unicorn) is
configured (as it should be!) to not serve static content from public in
production. It's your front-end server's job to serve static assets.

If you get an error in gitlab's (rails') log then your front-end server is
not configured properly to serve static files. My previous comment shows how
to configure nginx to check if a static files can be served before passing
the request to Gitlab.


Reply to this email directly or view it on GitHub:
#348 (comment)

@chibani chibani closed this Apr 27, 2012
Contributor
chibani commented Apr 27, 2012

So, i've installed nginx and now it's ok.
Thanks ;)

if you using the Apache as a Proxy you have to negate the ProxyPass for the downloads

ProxyPass /uploads !

And don't forget to set the DocumentRoot for the VirtualHost, to tell Apache where to find the downloads

DocumentRoot /var/gitlab/gitlab/public

@globalcitizen globalcitizen referenced this issue in gitlabhq/gitlab-recipes Oct 1, 2012
Merged

Add upload fix #13

Contributor
pipozzz commented Nov 13, 2012

+1

swis commented Jul 28, 2013

Actually, this would be a security issue, since uploads are publicly available without any authentification by default (if not defined in nginx/apache config).

Member
axilleas commented Aug 5, 2013

@swis do you have anything else in mind that could fix this error and be also secure?

swis commented Sep 14, 2013

It seems, that this is not an issue (at least) in 6.0 any more, since uploads are available only after GL login.

@Rovanion Rovanion pushed a commit to Rovanion/gitlabhq that referenced this issue Nov 15, 2013
@globalcitizen globalcitizen Add upload fix for issue at gitlabhq#348 343b1f5
@Rovanion Rovanion pushed a commit to Rovanion/gitlabhq that referenced this issue Nov 15, 2013
@axilleas axilleas Enhance existing apache config. Implement #50 and #79
Beware that adding `ProxyPass /uploads !` would be a security issue,
since uploads are publicly available without any authentification by default.

See: gitlabhq#348 (comment)
fabeb6a
@Rovanion Rovanion pushed a commit to Rovanion/gitlabhq that referenced this issue Nov 15, 2013
@axilleas axilleas Enhance existing apache config. Implement #50, #79, #93. Fix #10
Beware that adding `ProxyPass /uploads !` would be a security issue,
since uploads are publicly available without any authentification by default.

See: gitlabhq#348 (comment)
be95bd4
@allysonbarros allysonbarros pushed a commit to allysonbarros/gitlabhq that referenced this issue May 19, 2014
Allyson Barros [edu] Adicionando login_required nas views citada no Issue #348. ffbb58c
xdanx commented Sep 25, 2014

Dear all, I would like to share with you my version of nginx config that works with a custom install of Gitlab free edition , on a custom directory (https://server/gitlab/ )

  location /gitlab { # Notice the missing end / , in order to avoid 404 when peope hit https://server/gitlab 
    alias /home/git/gitlab/public/;
    ## Serve static files from defined root folder.
    ## @gitlab is a named location for the upstream fallback, see below.
    #try_files $uri $uri/;
    try_files $uri $uri/index.html $uri.html @gitlab;
  }

As you can see I have a custom directory called /gitlab (well, not so custom after all), and nginx is serving my files directly from the correct folder: /home/git/gitlab/public/ . If nginx cannot find a file, then it will pass the request to @gitlab upstream.

I personally feel that config.serve_static_assets = true in /home/git/gitlab/config/environments/production.rb shold NOT be used as it's the web server's job to serve static files.

@randx randx pushed a commit that referenced this issue Apr 14, 2015
@bbodenmiller bbodenmiller fix stuck MR
fixes #348. related to 6487419.
fb1cd0a
@DouweM DouweM added a commit that referenced this issue Apr 14, 2015
@DouweM DouweM Merge branch 'fix-stuck-mr' into 'master'
fix stuck MR

If `locked_at` is `nil` return that the merge has been locked long enough and those are old merges stuck in locked state.

Fixes #348. Related to 6487419.

See merge request !517
79b4d0b
@randx randx pushed a commit that referenced this issue Apr 15, 2015
@bbodenmiller bbodenmiller fix stuck mr
fixes #348. related to 6487419.
f517dd2
@DouweM DouweM added a commit that referenced this issue Apr 15, 2015
@DouweM DouweM Merge branch 'fix-stuck-mr' into 'master'
fix stuck mr

If `locked?` & `locked_at.nil?` is nil return that the merge has been locked long enough and those are old merges stuck in locked state.

Fixes #348. Related to 6487419. Replaces !517.

/cc @DouweM

See merge request !526
b409c37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment