I’ve never had a problem running Discourse on CentOS in the past, but I’m suddenly unable to build it for some reason on a new CentOS 7.3 EC2 instance.
While building, the errors begin with:
I, [2017-03-02T05:29:38.051256 #13] INFO -- : > cd /var/www/discourse && chown -R discourse /var/www/discourse
chown: cannot access '/var/www/discourse/app/assets/javascripts/discourse/helpers/max-usernames.js.es6': No such file or directory
chown: cannot access '/var/www/discourse/lib/locale_file_walker.rb': No such file or directory
…and the build fails with:
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && chown -R discourse /var/www/discourse failed with return #<Process::Status: pid 275 exit 1>
Location of failure: /pups/lib/pups/exec_command.rb:108:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"web", "cmd"=>["gem update bundler", "chown -R discourse $home"]}
Although not my usual approach, I followed the supported directions and continued to get identical errors. Here are the supported steps I’ve used on CentOS 7.3 with Docker 1.13.1 (build 092cba3) to reproduce the errors:
mkdir /var/discourse
git clone https://github.com/discourse/discourse_docker.git /var/discourse
cd /var/discourse
./discourse-setup
Do you ever do a chmod, chown, or similar in your Dockerfile? Most dockerfiles I’ve seen do absolutely everything as root, so they don’t hit this particular bug.
It’s a filesystem-creation-time option. According to the source post:
So what does docker info have to say on your system?
The best practice for using CentOS with EC2 is to use the officially-supported AMIs, so I’m not sure I have control over that. At least one of the issues in that post referenced a fix, but I’m running the latest Docker build from their official Yum repository, so I assume that either that fix isn’t apparent in my build or I’m running into an unresolved issue.
The two issues linked to in this post were #9572 (filed in 2014 and not XFS specific) and #27358 which was acknowledged as not a Docker bug (and which led to the change to make it obvious in docker info that Supports d_type: false).
This is not a bug in Docker. You are running a configuration that does not work, and absent some changes to the kernel, cannot work. Your options are as previously described in this post.