mix release fails with 'no case clause matching: :eacces'

[tgodfrey]

I'm following the Advanced Deployment instructions here: http://www.phoenixframework.org/docs/advanced-deployment, and I keep running into the same error when building the actual release.

I'm able to run the following successfully:

MIX_ENV=prod mix phoenix.digest
MIX_ENV=prod mix compile

Then, when I run MIX_ENV=prod mix release, I get the following error:

mariposa:atoms_portal tyler$ MIX_ENV=prod mix release --verbosity=verbose
Building release with MIX_ENV=prod.
==> Generating relx configuration...
==> Generating sys.config...
==> Generating vm.args...
==> Generating boot script...
==> Packaging consolidated protocols...
==> Generating release...
** (CaseClauseError) no case clause matching: :eacces
    lib/exrm/utils/utils.ex:110: ReleaseManager.Utils.relx/5
    lib/mix/tasks/release.ex:339: anonymous fn/4 in Mix.Tasks.Release.do_release/1
    lib/ex_unit/capture_io.ex:146: ExUnit.CaptureIO.do_capture_io/2
    lib/ex_unit/capture_io.ex:119: ExUnit.CaptureIO.do_capture_io/3
    lib/mix/tasks/release.ex:338: Mix.Tasks.Release.do_release/1
    lib/mix/tasks/release.ex:78: Mix.Tasks.Release.do_run/1
    (mix) lib/mix/task.ex:296: Mix.Task.run_task/3
    (mix) lib/mix/cli.ex:58: Mix.CLI.run_task/2

It's my understanding that :eacces indicates a file system permissions issue. I've checked the filesystem permissions, it all looks correct. All directories are 755; files are 644; everything is owned by me. I also moved the entire code base to a volume on my computer where I've set the volume to ignore ownership. All to no avail.

I'm at a loss at this point. I'm guessing it's either something simple, something obvious, or both, but I just can't see it. Any help would be appreciated.

OS: macOS Sierra (Darwin mariposa.local 16.1.0 Darwin Kernel Version 16.1.0: Thu Oct 13 21:26:57 PDT 2016; root:xnu-3789.21.3~60/RELEASE_X86_64 x86_64)

Elixir:

Erlang/OTP 19 [erts-8.1] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] [dtrace]

Elixir 1.3.4

Phoenix 1.2.1

mix.exs:

defmodule AtomsPortal.Mixfile do
 use Mix.Project

 def project do
 [app: :atoms_portal,
 version: "0.0.1",
 elixir: "~> 1.2",
 elixirc_paths: elixirc_paths(Mix.env),
 compilers: [:phoenix, :gettext] ++ Mix.compilers,
 build_embedded: Mix.env == :prod,
 start_permanent: Mix.env == :prod,
 aliases: aliases(),
 deps: deps()]
 end

 # Configuration for the OTP application.
 #
 # Type `mix help compile.app` for more information.
 def application do
 [mod: {AtomsPortal, []},
 applications: [:phoenix, :phoenix_pubsub, :phoenix_html, :cowboy, :logger, :gettext,
 :phoenix_ecto, :postgrex, :comeonin, :mailgun, :poison, :timex, :cors_plug]]
 end

 # Specifies which paths to compile per environment.
 defp elixirc_paths(:test), do: ["lib", "web", "test/support"]
 defp elixirc_paths(_), do: ["lib", "web"]

 # Specifies your project dependencies.
 #
 # Type `mix help deps` for examples and options.
 defp deps do
 [{:phoenix, "~> 1.2.0"},
 {:phoenix_pubsub, "~> 1.0"},
 {:phoenix_ecto, "~> 3.0"},
 {:postgrex, ">= 0.0.0"},
 {:phoenix_html, "~> 2.6"},
 {:phoenix_live_reload, "~> 1.0", only: :dev},
 {:gettext, "~> 0.11"},
 {:cowboy, "~> 1.0"},
 {:comeonin, "~> 2.0"},
 {:mailgun, "~> 0.1.2"},
 {:poison, "~> 2.1.0", override: true},
 {:timex, "~> 3.1.1"},
 {:cors_plug, "~> 1.1"},
 {:exrm, "~> 1.0"}]
 end

 # Aliases are shortcuts or tasks specific to the current project.
 # For example, to create, migrate and run the seeds file at once:
 #
 # $ mix ecto.setup
 #
 # See the documentation for `Mix` for more info on aliases.
 defp aliases do
 ["ecto.setup": ["ecto.create", "ecto.migrate", "run priv/repo/seeds.exs"],
 "ecto.reset": ["ecto.drop", "ecto.setup"],
 "test": ["ecto.create --quiet", "ecto.migrate", "test"]]
 end
end

mariposa:atoms_portal tyler$ mix hex.info
Hex:    0.14.1
Elixir: 1.3.4
OTP:    19.1

Built with: Elixir 1.3.4 and OTP 18.3.4.4
mariposa:atoms_portal tyler$ mix hex.outdated
Dependency           Current  Latest  Requirement  
comeonin             2.6.0    3.0.0   ~> 2.0       
cors_plug            1.1.2    1.1.2   ~> 1.1       
cowboy               1.0.4    1.0.4   ~> 1.0       
exrm                 1.0.8    1.0.8   ~> 1.0       
gettext              0.12.2   0.12.2  ~> 0.11      
mailgun              0.1.2    0.1.2   ~> 0.1.2     
phoenix              1.2.1    1.2.1   ~> 1.2.0     
phoenix_ecto         3.0.1    3.0.1   ~> 3.0       
phoenix_html         2.8.0    2.8.0   ~> 2.6       
phoenix_live_reload  1.0.6    1.0.6   ~> 1.0       
phoenix_pubsub       1.0.1    1.0.1   ~> 1.0       
poison               2.1.0    3.0.0   ~> 2.1.0     
postgrex             0.12.1   0.12.1  >= 0.0.0     
timex                3.1.5    3.1.5   ~> 3.1.1

Thanks!

-Tyler

[fmnxl]

I used sudo and it went through

[raarts]

Why would it need sudo just to build a release package?

[bingoabs]

I feel so confused by the same result ,and @freemanon 's way is right, thank you !But still don't understand why need 'sudo'!...

[raarts]

Phoenix is switching to distillery, which is kind of a drop-in replacement. I switched to it without issues.

[tgodfrey]

I'm going to close this issue, because it has become moot in my workflow. I'm deploying to Ubuntu, and so I'm developing on MacOS, building on an Ubuntu VM, and then deploying to an Ubuntu prod VM, so the building issues on MacOS don't matter to me.

I agree with @raarts - requiring 'sudo' to do a build seems very wrong. It raises all sorts of red flags, and potential problems. There's obviously some type of privileges issue somewhere, but why only on MacOS? What exactly is it trying to run that it can't unless run as a privileged user?

Anyhow, I'll try distillery, and see if that will work for me. Thanks for the input!

[bitwalker]

I've never had to use sudo with either exrm or distillery on OSX, so it's not clear to me what's causing this to occur as I'm unable to reproduce.

[raarts]

On linux I would use something like strace -f -e trace=file mix release to check which file is being accessed. If only I knew how to do this on OSX....

[carusso]

I came across this same problem yesterday. I resisted trying the sudo solution because I'm suspicious of anything that requires sudo from a security perspective and because I figured there could be unmalicious but annoying file ownership side effects. I added some debugging code and determined that the problem was occurring somewhere within the relx run. I also saw another problem report to the relx application developers that indicated that they sometimes have these file permission issues when creating the release. https://github.com/erlware/relx/issues/120

Since I have a deadline and mostly narrowed down where the problem was, I gave up and just used sudo.

Keep in mind that after you recompile everything with sudo that you'll need to go back and chown everything back to your regular user.