Aurus7
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.
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Phoenix, LiveView, multimedia pipelines, distributed systems. 400 engineers, Elixir since 2017. Available for hire.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixir-ls
- #elixirconf-us
- #ai
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 7- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
OvermindDL1
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.
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.
KokoAleksander
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.
Aurus7
Thanks for the detailed explanation. Running the shell as Administrator fixed it for the reasons you mentioned.
OvermindDL1
Nope, not brunch or node or even the BEAM, just how Windows works with lots of file changes very fast.
Awesome, glad to help.
KokoAleksander
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.
jakejgordon
I can confirm that deleting the _build/*/priv folder manually does solve the problem. Thanks @OvermindDL1!
DaAnalyst
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):
Phoenix should no longer have issues deleting the ‘../priv’ symlink