This error occurs when Git running in WSL (Windows Subsystem for Linux) cannot write to a config file due to Windows/Linux filesystem interoperability issues. The fix involves using Linux-native paths, configuring WSL mount options, or ensuring proper file permissions between the two systems.
The "could not lock config file: Input/output error" message indicates that Git is unable to create or write to a configuration file. When this occurs specifically in WSL (Windows Subsystem for Linux), it's almost always caused by filesystem interoperability problems between Windows and Linux. WSL allows you to access Windows files from Linux (typically mounted under `/mnt/c/`, `/mnt/d/`, etc.), but this cross-filesystem access introduces several issues: - **File locking differences**: Windows and Linux handle file locks differently. Windows uses mandatory locking while Linux uses advisory locking. This mismatch can cause lock operations to fail. - **Permission mapping issues**: Linux file permissions (chmod) don't translate perfectly to Windows NTFS permissions. - **Case sensitivity conflicts**: Windows filesystems are case-insensitive by default, while Linux is case-sensitive. - **Metadata translation overhead**: WSL must translate between NTFS and Linux filesystem semantics, which can fail under certain conditions. This error is especially common when: - Running Git in WSL on a repository stored on the Windows filesystem (`/mnt/c/...`) - Antivirus software or Windows Defender is scanning files - OneDrive or other sync software is interfering with file operations - The Windows disk has I/O issues or is low on space
The most reliable fix is to store your Git repositories on the Linux filesystem instead of the Windows filesystem. WSL 2 stores Linux files in a virtual disk that doesn't have interoperability issues.
Move your repository:
# Create a projects directory in your Linux home
mkdir -p ~/projects
# Copy the repository from Windows to Linux
cp -r /mnt/c/Users/YourName/projects/your-repo ~/projects/
# Navigate to the new location
cd ~/projects/your-repo
# Verify Git works
git statusAccess Linux files from Windows:
You can still access your Linux files from Windows via:
\\wsl$\Ubuntu\home\yourusername\projectsThis path works in File Explorer and most Windows applications.
Performance bonus: Git operations on the Linux filesystem are significantly faster (often 5-10x) compared to accessing Windows files through /mnt/.
If you must keep repositories on the Windows filesystem, enable metadata support in WSL to improve file permission handling.
Create or edit /etc/wsl.conf:
sudo nano /etc/wsl.confAdd these options:
[automount]
enabled = true
options = "metadata,umask=22,fmask=11"
root = /mnt/
[interop]
enabled = true
appendWindowsPath = trueExplanation:
- metadata: Stores Linux permissions as NTFS extended attributes
- umask=22: Sets default permissions for directories (755)
- fmask=11: Sets default permissions for files (644)
Restart WSL for changes to take effect:
# In PowerShell (as Administrator)
wsl --shutdown
# Then reopen your WSL terminalAfter restarting, try your Git operations again.
Windows Defender and other antivirus software can interfere with Git operations by holding file locks during scanning.
Add exclusions in Windows Security:
1. Open Windows Security (search "Windows Security" in Start menu)
2. Go to "Virus & threat protection"
3. Under "Virus & threat protection settings", click "Manage settings"
4. Scroll to "Exclusions" and click "Add or remove exclusions"
5. Add folder exclusions for:
- Your Git repositories folder
- C:\Users\YourName\.gitconfig
- WSL installation: %LOCALAPPDATA%\Packages\CanonicalGroupLimited.Ubuntu*
Or via PowerShell (as Administrator):
# Exclude your projects folder
Add-MpPreference -ExclusionPath "C:\Users\YourName\projects"
# Exclude WSL distribution
Add-MpPreference -ExclusionPath "$env:LOCALAPPDATA\Packages\CanonicalGroupLimited.Ubuntu*"
# Verify exclusions
Get-MpPreference | Select-Object -ExpandProperty ExclusionPathFor third-party antivirus, consult your antivirus documentation for adding folder exclusions.
OneDrive, Dropbox, Google Drive, and other cloud sync services can cause file locking conflicts with Git.
For OneDrive:
1. Right-click the repository folder in File Explorer
2. Select "Free up space" or "Always keep on this device" to prevent sync conflicts
3. Or move the repository outside OneDrive folders entirely
Better approach - use .gitignore for sync services:
If your repository is in a synced folder, the sync service may conflict with Git's internal files.
Exclude Git internals from OneDrive:
# In PowerShell, add .git folders to OneDrive exclusion
# Note: OneDrive doesn't have built-in folder exclusion, so moving is preferredBest practice: Keep Git repositories in a non-synced folder:
# Move from OneDrive folder to a non-synced location
mv /mnt/c/Users/YourName/OneDrive/projects /mnt/c/Users/YourName/projects
# Or better yet, move to Linux filesystem
mv /mnt/c/Users/YourName/OneDrive/projects ~/projectsOneDrive and Git both track file changes, and they don't play well together. Use one or the other, not both.
The "Input/output error" can indicate underlying disk problems on Windows.
Check disk space:
# Check Windows drive space from WSL
df -h /mnt/c
# Check if the drive is nearly full
# Git needs space for temp files and lock filesCheck disk health from Windows:
# In PowerShell (as Administrator)
chkdsk C: /F /R
# This will schedule a check on next reboot for the system driveCheck for NTFS errors:
# Repair Windows image issues
DISM /Online /Cleanup-Image /RestoreHealth
# Verify system file integrity
sfc /scannowCheck WSL disk image:
# WSL 2 uses a virtual disk - optimize it
wsl --shutdown
Optimize-VHD -Path "$env:LOCALAPPDATA\Packages\CanonicalGroupLimited.Ubuntu*\LocalState\ext4.vhdx" -Mode FullIf disk checks reveal errors, address them before continuing with Git operations.
If you must work with repositories on the Windows filesystem, consider using Windows Git instead of WSL Git.
Install Git for Windows:
Download from https://git-scm.com/download/win
Configure WSL to use Windows Git for Windows paths:
Create a wrapper script:
# Create ~/bin if it doesn't exist
mkdir -p ~/bin
# Create a smart git wrapper
cat > ~/bin/git-smart << 'EOF'
#!/bin/bash
# Use Windows Git for Windows paths, Linux Git otherwise
if [[ "$PWD" == /mnt/* ]]; then
git.exe "$@"
else
/usr/bin/git "$@"
fi
EOF
chmod +x ~/bin/git-smartAdd to your PATH in ~/.bashrc:
export PATH="$HOME/bin:$PATH"
alias git='git-smart'Or simply use git.exe directly:
# When in /mnt/c/... paths
git.exe status
git.exe commit -m "message"
git.exe pushThis approach uses Windows-native file operations and avoids the WSL filesystem translation layer entirely.
If the error persists and seems to be a WSL-level issue, updating or reinstalling WSL may help.
Update WSL:
# In PowerShell (as Administrator)
wsl --update
# Check WSL version
wsl --versionConvert to WSL 2 if using WSL 1:
# Check current version
wsl -l -v
# Convert to WSL 2 if needed
wsl --set-version Ubuntu 2Reset WSL if corrupted:
# Export your data first!
wsl --export Ubuntu ubuntu-backup.tar
# Unregister the distribution
wsl --unregister Ubuntu
# Reinstall from Microsoft Store or:
wsl --install -d Ubuntu
# Restore your data
wsl --import Ubuntu C:\WSL\Ubuntu ubuntu-backup.tarAlternative - clean reinstall:
1. Backup your Linux home directory
2. Uninstall Ubuntu from Windows Settings > Apps
3. Reinstall from Microsoft Store
4. Restore your files
After reinstalling, the filesystem interoperability layer will be reset to defaults.
Understanding WSL Filesystem Architecture:
WSL 2 runs a real Linux kernel in a lightweight VM, with two distinct filesystem types:
1. Linux filesystem (ext4): Stored in a virtual disk (ext4.vhdx). This is your /home, /etc, /usr, etc. Git operations here work exactly like native Linux.
2. Windows filesystem (9P): Accessed via /mnt/c, /mnt/d, etc. WSL uses the 9P protocol to access Windows files through the VM boundary. This translation layer is where I/O errors typically originate.
Why the 9P filesystem causes Git issues:
The 9P protocol must translate between:
- File locking semantics: Git uses fcntl() locks on Linux; Windows uses different locking mechanisms
- Permissions: Linux modes (644, 755) vs Windows ACLs
- Case sensitivity: Linux is case-sensitive, Windows NTFS is case-insensitive by default
- Special files: Symlinks, FIFOs, and other Unix constructs don't exist natively on Windows
When any of these translations fail, you get I/O errors.
The metadata Mount Option:
When you add metadata to mount options, WSL stores Linux permission information in NTFS extended attributes. Without it:
# Without metadata
ls -la /mnt/c/Users
# All files show as owned by root with 777 permissions
# With metadata
ls -la /mnt/c/Users
# Files show proper ownership and permissionsHowever, metadata doesn't fix locking issues, which is why moving to Linux filesystem is the most reliable solution.
DrvFs vs 9P in WSL Versions:
- WSL 1: Uses DrvFs driver, runs Linux binaries via syscall translation. Faster file access but less compatible.
- WSL 2: Uses 9P protocol over Hyper-V socket. Better compatibility but slower cross-filesystem access.
Neither is perfect for Git on Windows filesystems, which is why the Linux filesystem is recommended.
Performance Implications:
File operations on /mnt/c in WSL 2 are 3-6x slower than native Windows and 5-10x slower than the Linux filesystem:
# Benchmark Git on Windows filesystem
time git status # in /mnt/c/project - slow
# Benchmark Git on Linux filesystem
time git status # in ~/project - fastFor large repositories with thousands of files, the performance difference is dramatic.
Concurrent Access Patterns:
Avoid accessing the same Git repository simultaneously from:
- WSL Git and Windows Git
- WSL Git and Windows IDEs (VS Code, JetBrains)
- Multiple WSL distributions
Each access pattern can create conflicting locks. If using VS Code with WSL, use the "Remote - WSL" extension so VS Code runs inside WSL, not outside it.
Git Configuration for WSL:
Set these Git configs when working in WSL:
# Handle line ending differences
git config --global core.autocrlf input
# Disable executable bit detection on Windows paths (if needed)
git config --global core.filemode false
# Set default branch to main
git config --global init.defaultBranch mainVS Code Integration:
For the best experience with WSL and Git:
1. Install the "Remote - WSL" extension
2. Open VS Code from within WSL: code .
3. This runs the VS Code server inside WSL, eliminating cross-filesystem issues
4. Git operations happen entirely within WSL
Debugging I/O Errors:
If you need to diagnose the exact cause:
# Trace file operations
strace git status 2>&1 | grep -E "(open|lock|fcntl|EIO)"
# Check dmesg for I/O errors
dmesg | tail -50
# Check Windows Event Viewer for disk errors
# Run: eventvwr.msc in WindowsCorporate/Enterprise Considerations:
In enterprise environments, additional factors may cause this error:
- Group Policy restrictions on file operations
- Enterprise antivirus with aggressive file scanning
- DLP (Data Loss Prevention) software monitoring file access
- Encrypted filesystems (BitLocker issues with WSL)
Consult your IT department if corporate software is suspected.
kex_exchange_identification: Connection closed by remote host
Connection closed by remote host when connecting to Git server
fatal: unable to access: Proxy auto-configuration failed
How to fix 'Proxy auto-configuration failed' in Git
fatal: unable to access: Authentication failed (proxy requires basic auth)
How to fix 'Authentication failed (proxy requires basic auth)' in Git
fatal: unable to access: no_proxy configuration not working
How to fix 'no_proxy configuration not working' in Git
fatal: unable to read tree object in treeless clone
How to fix 'unable to read tree object in treeless clone' in Git