Fix Windows 'ENOENT: no such file or directory' with Long Paths (> 260 chars)

beginner๐ŸชŸ Windows2026-04-15| Windows 10/11, Node.js, npm, Git for Windows, Python

Error Message

ENOENT: no such file or directory (path too long > 260 chars)
#windows#path#long-path#nodejs#npm

TL;DR โ€” Quick Fix

Windows caps file paths at 260 characters (the MAX_PATH limit). One command fixes it system-wide โ€” run PowerShell as Administrator:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\FileSystem" /v LongPathsEnabled /t REG_DWORD /d 1 /f

Reboot. Then, for Node.js/npm, also run:

npm config set long-paths true

On a corporate machine where Group Policy can overwrite registry changes, skip ahead to Fix 2.

What Actually Causes This

MAX_PATH is a relic from MS-DOS. Windows inherited the 260-character limit in Windows 95 and kept it โ€” for decades โ€” to avoid breaking old software that hard-coded that number.

Windows 10 version 1607 quietly added support for longer paths. The catch: it's disabled by default. You have to opt in.

Where this tends to blow up:

  • Deep node_modules nesting โ€” npm v2/v3 used to nest packages 10+ levels deep, easily pushing paths past 300 characters
  • Repos cloned into paths like C:\Users\johndoe\Documents\Work\Clients\AcmeCorp\2024\frontend\ (already 65 chars before a single file)
  • Python virtualenvs sitting inside already-deep project directories
  • Build tools like webpack or Vite generating temp files with long content-hashed names
  • Docker Desktop on Windows, where WSL2 mount paths add another layer of length

Fix 1 โ€” Enable Long Paths via Registry (Quickest)

Open PowerShell as Administrator and run:

# Enable long path support
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1

# Verify it's set
Get-ItemPropertyValue -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled"
# Should output: 1

Reboot after this โ€” the setting doesn't kick in until the next boot.

Fix 2 โ€” Enable Long Paths via Group Policy (Managed Machines)

Registry changes on corporate machines often get overwritten at next login. Group Policy is the right tool here:

  • Press Win + R, type gpedit.msc, hit Enter
  • Navigate to: Local Computer Policy โ†’ Computer Configuration โ†’ Administrative Templates โ†’ System โ†’ Filesystem
  • Double-click Enable Win32 long paths
  • Set to Enabled, click OK
  • Reboot

Note: gpedit.msc only exists on Windows Pro and Enterprise. Windows Home? Use Fix 1 instead.

Fix 3 โ€” npm / Node.js Specific

The OS-level fix alone isn't always enough. npm has its own flag:

# Set globally
npm config set long-paths true

# Verify
npm config get long-paths
# Should output: true

No admin rights? Move the project closer to the drive root. Compare the difference:

# 97 characters before you even reach src/:
# C:\Users\john\Documents\work\clients\acme-corp\projects\frontend\app

# 16 characters โ€” plenty of headroom:
# C:\dev\acme-frontend

This single change often eliminates the error without touching any system settings.

Fix 4 โ€” Git for Windows Long Path Support

Git maintains its own path length setting, independent of Windows:

# Enable globally
git config --global core.longpaths true

# Or just for the current repo
git config core.longpaths true

# Verify
git config --global --get core.longpaths
# Should output: true

Skip this and monorepo clones will keep failing even after the OS fix is applied.

Fix 5 โ€” Map a Long Path to a Drive Letter

When you can't change the path structure, fake a short one. The subst command maps any directory to a drive letter:

# Map a long project path to drive Z:
subst Z: "C:\Users\yourusername\Documents\Projects\company\repo"

# Work from Z:\ instead
cd Z:\
npm install

The mapping disappears on reboot. To keep it, add the subst command to a startup script or a scheduled task set to run at login.

Verifying the Fix

Before you run your build again, confirm the setting actually took effect:

# Check registry value (PowerShell)
(Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem").LongPathsEnabled
# Expected: 1

# Create a test directory with a 250-char name
$longPath = "C:\" + ("a" * 250)
New-Item -ItemType Directory -Path $longPath -ErrorAction SilentlyContinue
if (Test-Path $longPath) {
    Write-Host "Long paths work!"
    Remove-Item $longPath
} else {
    Write-Host "Long paths still NOT working โ€” did you reboot?"
}

If the test passes, re-run the original failing command (npm install, git clone, your build script). The ENOENT error should be gone.

No Admin Rights? Here's What Still Works

Admin access is required for Fixes 1 and 2 โ€” but you're not out of options:

  • Move the project to a shorter path โ€” the most reliable option, zero permissions needed
  • Use WSL2 โ€” the Linux filesystem inside WSL has no 260-char limit. Run your Node.js/npm commands from WSL and access project files via /mnt/c/...
  • Use npm's --prefix flag to install packages into a shorter path
  • Ask IT โ€” enabling long paths is a one-line registry change, affects nothing else, and takes under a minute to justify

Quick Reference

# 1. Enable long paths (Admin PowerShell)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1

# 2. npm long paths
npm config set long-paths true

# 3. Git long paths
git config --global core.longpaths true

# 4. Reboot

Related Error Notes