Nginx 404 (Not Found) only for rails images on AWS - ruby-on-rails

Question

Im testing my app in production mode and running into a weird problem. The image assets aren't loading on the webpage. All the css and javascript are loading fine but any image gets a 404 (Not Found) from nginx. Im pushing my app with docker to AWS services. When I precompile the assets the images are included in the output so they should be there:
I, [2017-08-30T12:10:50.092655 #7] INFO -- : Writing /livingrecipe/public/assets/default-user-d39e051d757a0f45602b6065147cec0a307c6a2a070834f6fe6fc2b0fc914207.jpg
I, [2017-08-30T12:10:50.104846 #7] INFO -- : Writing /livingrecipe/public/assets/default_recipe-be8d509a8e34dfec514c097b119753d4aaadbfd1dd6747e3c868ed454b8a36b3.jpg
I, [2017-08-30T12:10:50.108486 #7] INFO -- : Writing /livingrecipe/public/assets/edit-4e381318428d71d55ed0cbdc32b4ce99db6622140c6e7c751ae0f1bfb40d3963.png
I, [2017-08-30T12:10:50.111606 #7] INFO -- : Writing /livingrecipe/public/assets/favorite-91432751e505915d80cf4e24d7a8d0abd3493d05d2d447c1cebb055d99757ac8.png
I, [2017-08-30T12:10:50.115720 #7] INFO -- : Writing /livingrecipe/public/assets/icon_email-203dcd7bdcf7559d742f76a9d8c21e98694d45b9556b29ab9ce286a7dd37af11.png
I, [2017-08-30T12:10:50.118457 #7] INFO -- : Writing /livingrecipe/public/assets/icon_facebook-0140437ec6cb29bc6ac6f8505f05f11603a430298e48c1ea483f7de390ba34a9.png
I, [2017-08-30T12:10:50.121393 #7] INFO -- : Writing /livingrecipe/public/assets/icon_google-2a98026430dddc53539d283c04a2ad4b50536c93d0becadb03f3f61443e52c9c.png
I, [2017-08-30T12:10:50.125228 #7] INFO -- : Writing /livingrecipe/public/assets/star-half-db15fb9b3561d5c741d8aea9ef4f0957bd9bc51aa1caa6d7a5c316e083c1abd5.png
I, [2017-08-30T12:10:50.127714 #7] INFO -- : Writing /livingrecipe/public/assets/star-off-6aaeebdaab93d594c005d366ce0d94fba02e7a07fd03557dbee8482f04a91c22.png
I, [2017-08-30T12:10:50.130083 #7] INFO -- : Writing /livingrecipe/public/assets/star-on-fd26bf0ea0990cfd808f7540f958eed324b86fc609bf56ec2b3a5612cdfde5f5.png
I, [2017-08-30T12:10:50.132442 #7] INFO -- : Writing /livingrecipe/public/assets/unfavorite-7000a53c81f55cf94c88031a8529f847e5a6abd7460e0e54ae0b581b0cde85a3.png
And here is my default.conf file for the nginx:
upstream PLACEHOLDER_BACKEND_NAME {
# The web app.
server PLACEHOLDER_BACKEND_NAME:PLACEHOLDER_BACKEND_PORT;
}
# Redirect 'www' addresses to the non-www version, and also take care of
# redirects to HTTPS at the same time.
server {
listen 80;
server_name www.PLACEHOLDER_VHOST;
return 301 https://$host$request_uri;
}
server {
# "deferred" reduces the number of formalities between the server and client.
listen 80 default deferred;
server_name PLACEHOLDER_VHOST;
# Static asset path, which is read from the PLACEHOLDER_BACKEND_NAME
# container's VOLUME.
root /PLACEHOLDER_BACKEND_NAME/public;
# Serve static assets.
#
# gzip_static is enabled because the assets are already gzipped to a maximum
# level due to Rail's asset pipeline.
#
# Add headers to set the maximum amount of cache time.
#
# We can do this because the Ruby on Rails asset pipeline md5 hashes all of
# the file names for us. When a file changes, its md5 will change, and the
# cache will be automatically busted. Other frameworks can do this as well.
location ~ ^/assets/ {
gzip_static on;
# Set a maximum cache time period and null out a few headers to address
# certain browsers from occasionally requesting cached content.
expires max;
add_header Cache-Control public;
add_header Last-Modified "";
add_header ETag "";
}
# Ensure timeouts are equal across browsers.
keepalive_timeout 60;
# Disallow access to hidden files and directories.
location ~ /\. {
return 404;
access_log off;
log_not_found off;
}
# Allow optionally writing an index.html file to take precedence over the upstream.
try_files $uri $uri/index.html $uri.html #PLACEHOLDER_BACKEND_NAME;
# Attempt to load the favicon or fall back to status code 204.
location = /favicon.ico {
try_files /favicon.ico = 204;
access_log off;
log_not_found off;
}
# Force SSL connections on agents (browsers) who support this header.
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains;";
# Load the web app back end with proper headers.
location #PLACEHOLDER_BACKEND_NAME {
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Ssl on;
proxy_redirect off;
if ($http_x_forwarded_proto = "http") {
return 301 https://$host$request_uri;
}
proxy_pass http://PLACEHOLDER_BACKEND_NAME;
}
}

Answer 1

I am going to answer from experience, although I had the same problem with Nginx + Django. What saved my situation is giving a user that runs the server (might be www-data, in my case was me) privilege to access images. Yes, it sounds stupid since it has permissions on other files, but that helped. Try
sudo chmod -R 750 /root/of/website
This will recursively give permission 750 to all files in that directory. Hope it helps!
Note: It might not be the problem so please do not downvote if it doesn't help.

Answer 2

So it was a simple mistake of wrong way to reference the assets. In rails I was using this:
<%= asset_path('/assets/image.png') %>
which in development mode still showed the assets but in production it couldnt find it cause it already adds the assets folder so was looking in assets/assets/image. Changed everything to:
<%= asset_path('image.png') %>
Like it should be and it worked just fine.