Mix ecto.gen.migration "could not remove file" error

Hi Everyone,

I’ve been working through Programming Phoenix, and the sample project “Rumbl”. At one point, we’re asked to create a migration with the command mix ecto.gen.migration add_category_id_to_video. When I do this, I get the error ** (File.Error) could not remove file "...rumbl/_build/dev/lib/rumbl/priv": not owner. Stack trace:

   (mix) lib/mix/utils.ex:312: Mix.Utils.symlink_or_copy/2
   (mix) lib/mix/project.ex:414: Mix.Project.build_structure/2
   (mix) lib/mix/tasks/compile.all.ex:15: Mix.Tasks.Compile.All.run/1
   (mix) lib/mix/task.ex:296: Mix.Task.run_task/3
   (mix) lib/mix/tasks/compile.ex:85: Mix.Tasks.Compile.run/1
   (mix) lib/mix/task.ex:296: Mix.Task.run_task/3
   lib/mix/ecto.ex:61: Mix.Ecto.ensure_repo/2```
 I definitely am the owner of that folder, and I'm able to get around this and run the command successfully by manually deleting that folder beforehand.  Is there something I'm missing here that would have caused this?  I'm also getting this error now when running `mix ecto.migrate`, which I'd been able to do successfully in this project in the past.  I'm on Windows 10, by the way.  Thanks for your time.
1 Like

You are not running with privileges that allow symlinking, so Phoenix has to copy the priv directory instead of link it. However with it being copied creates race conditions. Assuming you are running recent versions of Phoenix/Elixir you should have got a message in your terminal that stated that if you are not running without symlink privileges or something like that they you will experience significant performance degradation during development in addition to various errors. The error you get of ‘not owner’ is because the Windows file system has not finished synching files in the background so it is ‘owned’ by ‘SYSTEM’ at that second, but it reverts back to you when it is done (most of the time, if a copy happens while another is still synching in the background it can get perma-stuck). Yes NTFS sucks.

Either give your user access to permission to create symlinks, or run the server with admin permissions. It is a limitation of Windows, it cannot keep up with the code reloading and gets stuck like that when it happens rapidly, but by giving the server symlink (or admin) permissions (Why does windows not give it by default?!? Stupid…) then Phoenix can work-around the issue by just symlinking so there is only ever one copy. :slight_smile:

Source: I was the one that discovered this issue, it is native to Windows and how fast the BEAM compiles (too fast) and found the work-around, consequently I was the one that suggested that the message be added to the terminal (and it still reminds me to this day when I forget to elevate the server process). ^.^

EDIT: You may need to manually delete that directory ‘one-more-time’ to let the symlink happen, but that is a toss-up on whether it is required or not too.


Hi. Also new to Phoenix. Maybe there’s something related to Brunch (node) running as Administrator. I’m not much sure on this but maybe when building (also copies priv folder to _build folder), it can delete because is not the owner.

Not totally sure if this is the issue, but it may be a Node related issue.


Thanks for the detailed explanation. Running the shell as Administrator fixed it for the reasons you mentioned.


Nope, not brunch or node or even the BEAM, just how Windows works with lots of file changes very fast.

Awesome, glad to help. :slight_smile:


Love what NTFS still does. I recall some weird stuff when was developing PHP + Composer on Windows. When wanted to delete the vendor folder, in some cases there were many files nested in some cases with long names, and NTFS just failed on those cases.


I can confirm that deleting the _build/*/priv folder manually does solve the problem. Thanks @OvermindDL1!

1 Like

I have also encountered this problem with Phoenix Framework ‘Hello’ demo application on Windows. In my case, the symlink ‘…/priv’ tends to be created successfully by Phoenix (over and over again as the web page is refreshed), so deleting it manually won’t help, unless one is fine with repeatedly manually deleting the symlink.

The solutions is as follows (thanks to a buddy of mine):

  1. Display the properties of the project folder (or better, a root folder of all Elixir projects on the windows machine).
  2. In the Security tab, add your windows user name (don’t forget to click Check name)
  3. Give full control permission over the folder to this user.
  4. Wait until windows applies this change recursively on the entire folder structure.
  5. Use classic cmd shell (Git Bash, for example, won’t do, don’t ask me why) and launch the server in the project directory (mix phx.server).

Phoenix should no longer have issues deleting the ‘…/priv’ symlink

1 Like