How to fix npm ERR! code ETXTBSY npm ERR! ETXTBSY: text file is busy in npm

npmINTERMEDIATEHIGHUpdated Dec 5, 2025ยท 152 views

ETXTBSY occurs when npm attempts to modify or delete a file that is currently in use by another process. This is common in virtualized environments, shared folders, and VM setups.

Quick fix

Fixes ETXTBSY

npm cache clean --force
rm -rf node_modules package-lock.json
npm install
  1. Clear npm cache and try again
  2. Use the --no-bin-links flag for virtual machines
  3. Move node_modules outside the shared folder (Vagrant/VirtualBox)
  4. Run npm from the host OS instead of guest VM
npm โ€” error
npm cache clean --force
rm -rf node_modules package-lock.json
npm install
npm ERR! code ETXTBSY
npm ERR! ETXTBSY: text file is busy

What this error means

ETXTBSY is a system-level error that occurs when npm attempts to modify or delete a file that is currently in use by another process. The error stands for 'text file is busy' and typically happens during npm install when npm tries to rename, unlink, or modify files in your node_modules directory. This error is especially common in virtualized environments, shared file systems, and situations where file locking mechanisms prevent npm from making necessary changes to package files. VirtualBox/Vagrant shared folders are particularly prone to this issue.

Typical symptoms

  • npm install fails with 'ETXTBSY: text file is busy, rename' or 'unlink' error messages
  • Installation process hangs or stalls before ultimately failing with ETXTBSY
  • Error only occurs when running npm commands inside virtual machines or shared folders
  • Multiple files report the busy status, but the actual blocking file is unclear
  • npm works fine on the host OS but fails within guest VM or Docker container

Common causes

  1. VirtualBox/Vagrant shared folders don't support symlinks properly, causing file locking conflicts
  2. Running npm install inside a shared folder between host (Windows) and guest (Linux) VM
  3. Running npm with Node.js on Rosetta emulation on Apple Silicon Macs with certain Docker images
  4. Antivirus software, file indexing services, or IDEs actively scanning or locking node_modules files
  5. Running npm in Docker on Windows hosts without proper volume mount configuration
  6. npm version compatibility issues with the virtualization layer

How to fix "npm ERR! code ETXTBSY npm ERR! ETXTBSY: text file is busy"

1Clear npm cache and try again

Sometimes corrupted cache can cause file locking issues. Clear the npm cache completely and attempt a fresh install:

bash
npm cache clean --force
rm -rf node_modules package-lock.json
npm install
2Use the --no-bin-links flag for virtual machines

If you're running npm inside a VirtualBox shared folder or VM, the --no-bin-links flag prevents npm from creating symbolic links:

bash
npm install --no-bin-links
npm rebuild --no-bin-links

To make this permanent, add it to your .npmrc file:

bash
echo "bin-links=false" >> ~/.npmrc
3Move node_modules outside the shared folder (Vagrant/VirtualBox)

Create the node_modules directory in the VM's home directory and link to it:

bash
# Inside the VM
mkdir ~/node_modules
cd /vagrant/your-project
ln -sf ~/node_modules ./node_modules
npm install

Alternatively, add this to your Vagrantfile to enable symlinks:

ruby
config.vm.provider "virtualbox" do |vb|
  vb.customize ["setextradata", :id, "VBoxInternal2/SharedFoldersEnableSymlinksCreate/v-root", "1"]
end
4Run npm from the host OS instead of guest VM

If you're using Vagrant or VirtualBox, the most reliable solution is to run npm install directly from your Windows/Mac host:

bash
# Exit vagrant SSH and run from your host OS
exit
npm install

This avoids the file system compatibility issues entirely.

5Disable antivirus/file scanning during installation

If running on Windows or Mac natively, antivirus or file indexing services might be locking files:

Windows Defender:

powershell
# Disable Windows Defender temporarily
Set-MpPreference -DisableRealtimeMonitoring $true
npm install
# Re-enable after installation
Set-MpPreference -DisableRealtimeMonitoring $false

Alternatively, exclude your project folder from real-time scanning in antivirus settings.

6Use yarn instead of npm as a workaround

If npm continues to fail, switch to yarn which has better handling of file locks:

bash
# Install yarn globally
npm install -g yarn

# Remove npm artifacts
rm -rf node_modules package-lock.json

# Install using yarn
yarn install

Advanced notes

The ETXTBSY error is fundamentally a file system permissions and symlink support issue. On Windows with VirtualBox/Vagrant, the problem occurs because Windows shares folders with Linux VMs without native symlink support, and npm tries to create symlinks in node_modules. Some Docker images on Apple Silicon Macs using Rosetta emulation have also reported this issue. For CI/CD pipelines, this error is rare because they run in proper Linux environments; if it occurs there, check that your Docker image is compatible with your host architecture.

Frequently asked questions

What does "ETXTBSY" mean?
ETXTBSY is a system-level error that occurs when npm attempts to modify or delete a file that is currently in use by another process. The error stands for 'text file is busy' and typically happens during npm install when npm tries to rename, unlink, or modify files in your node_modules directory. This error is especially common in virtualized environments, shared file systems, and situations where file locking mechanisms prevent npm from making necessary changes to package files.
How do I fix "ETXTBSY"?
ETXTBSY occurs when npm attempts to modify or delete a file that is currently in use by another process. This is common in virtualized environments, shared folders, and VM setups.
What causes "ETXTBSY"?
VirtualBox/Vagrant shared folders don't support symlinks properly, causing file locking conflicts Running npm install inside a shared folder between host (Windows) and guest (Linux) VM Running npm with Node.js on Rosetta emulation on Apple Silicon Macs with certain Docker images
Is the "ETXTBSY" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading