cannot move 'node_modules' to '_del_node_modules/node_modules': Permission denied

Question

cannot move 'node_modules' to '_del_node_modules/node_modules': Permission denied

Graham 86

I've noticed the following error in my node.js App Service Linux App on startup:

"mv: cannot move 'node_modules' to '_del_node_modules/node_modules': Permission denied"

The app normally starts up fine but recently I updated a package version in package.json and the app would not start up because the new package was not getting installed.

Upon investigating I found that the the node_modules.tar.gz archive was getting updated, but not the node_modules folder that node.js actually reads from. It looks like the startup script that is supposed to unzip node_modules and copy them to the correct folder is failing with permission denied.

I'm not quite sure how to fix this. I was able to mitigate it by connecting via ssh and manually running npm install in wwwroot. This makes sure node_modules has up-to-date packages but does not seem like a viable long-term solution for process that is supposed to be automated.

I do have another Linux Web App and I connected to both via ssh, ran ls -l, and noticed that both node_modules and _del_node_modules are both supposed to be symbolic links and not directories. For some reason on my broken app they are directories.

I'm not sure how to fix this aside from maybe deleting the entire app and recreating from scratch. Any help would be appreciated.

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Michele Ariis 7,210 MVP Volunteer Moderator

Hi, this happens because node_modules and _del_node_modules stopped being symlinks and became real folders. When that happens, the App Service startup script can’t move them and fails with “permission denied”.

The fix is to SSH into the app, delete both node_modules and _del_node_modules, then restart or redeploy the app. App Service will recreate them as symlinks and package installs will work again.

Graham 86 Reputation points

2026-01-19T14:55:40.5966667+00:00

Thanks. I actually tried to do this, rm -rf _del_node_modules, but the command just hangs. I've tried to do this via kudu bash and ssh. I figured that maybe the files are locked when the app is running, but when I stop the app I am unable to connect via ssh since the container is not running. I can still connect via kudu bash but I don't think the kudu_ssh_user has the correct permissions to modify these folders anyway.

Perhaps I'm doing something silly here. How can I delete the folders?
Graham 86 Reputation points

2026-01-19T15:18:11.6533333+00:00

Actually I spoke a bit too soon. It seems as of this morning I am no longer getting the Permission denied error. Perhaps the delete command did actually run but was just blocked until the container stopped running. I can see that node_modules is now correctly set to be a symlink.

Strangely enough _del_node_modules is still a regular folder and not a symlink which is inconsistent with the other app service instances, whereas I only tried to remove _del_node_modules and did not attempt anything on node_modules. Not sure if this matters.
Michele Ariis 7,210 Reputation points MVP Volunteer Moderator

2026-01-19T15:24:04.4866667+00:00

The error happens because node_modules and/or _del_node_modules stopped being symlinks and became real directories. When that occurs, the Azure App Service startup script (Oryx) can no longer move them during startup, and it fails with “Permission denied”.

The reason rm -rf _del_node_modules appeared to hang is that deleting node_modules on App Service Linux can be very slow due to the huge number of files and the underlying storage. It usually isn’t locked; it’s just taking a long time. In your case, the delete likely completed later, which explains why the error disappeared the next day and node_modules became a symlink again.

The correct fix is:

-Use Kudu (Advanced Tools) - Bash

-Go to /home/site/wwwroot

-Delete both node_modules and _del_node_modules

-Restart or redeploy the app

App Service will recreate them correctly as symlinks on the next startup.

It’s generally not a problem if _del_node_modules remains a normal folder, as long as node_modules is restored properly and the app starts and installs packages correctly.

To prevent this in the future, avoid deploying node_modules directly and stick to a single, clean deployment strategy (build in CI or build in App Service, not both).
Graham 86 Reputation points

2026-01-20T14:20:33.8233333+00:00

Thanks for the explanation. I don't think I've ever deployed node_modules directly. It's always been generated by the Oryx build but somehow things must have gotten into a strange state.

Share via

cannot move 'node_modules' to '_del_node_modules/node_modules': Permission denied

0 additional answers

Your answer