This error occurs when Git cannot create lock files on an NFS-mounted filesystem because NFS file locking is disabled, misconfigured, or the lock daemon is not running. The fix involves either enabling NFS locking, using a local filesystem for the repository, or configuring Git to work around the limitation.
The "Unable to create lock file: No locks available" error on NFS filesystems indicates that Git's file locking mechanism is failing at the operating system level. Git relies heavily on lock files to prevent concurrent modifications and ensure data integrity, but NFS (Network File System) handles file locking differently than local filesystems. NFS uses a separate lock manager (lockd/statd on Linux) to coordinate file locks across networked clients. When this error occurs, it means one of the following: - **The NFS lock daemon (rpc.lockd/rpc.statd) is not running** on the client or server - **The NFS mount was created with the `nolock` option**, explicitly disabling locking - **The NFS server does not support or has disabled locking** - **A firewall is blocking the NFS lock ports** (typically UDP/TCP 32803 and 32769) The underlying system call returns ENOLCK (No locks available), which Git surfaces as this fatal error. Unlike the "index.lock exists" error where a stale lock file is the problem, this error means the system cannot create locks at all. This is particularly common when: - Working with Git repositories on NAS devices or networked storage - Using NFS home directories in enterprise or academic environments - Running containerized builds with NFS-mounted volumes - Working in cloud environments with shared file storage
First, check how the NFS filesystem is mounted and whether locking is enabled:
# Check mount options for all NFS mounts
mount | grep nfs
# Or check a specific mount point
mount | grep /path/to/your/repo
# Look for 'nolock' in the output - if present, locking is disabled
# Example output with locking disabled:
# server:/export on /mnt/nfs type nfs (rw,nolock,addr=192.168.1.100)You can also check /proc/mounts for more detail:
cat /proc/mounts | grep nfsIf you see nolock in the mount options, that's the cause. Proceed to remount with locking enabled.
If the mount has nolock set, remount it with locking enabled:
# Unmount the NFS share (ensure no processes are using it)
sudo umount /mnt/nfs
# Remount with locking enabled (remove nolock option)
sudo mount -t nfs -o rw,hard,intr server:/export /mnt/nfs
# Or if using NFSv4:
sudo mount -t nfs4 -o rw,hard,intr server:/export /mnt/nfsFor persistent changes, edit /etc/fstab:
# Before (locking disabled):
server:/export /mnt/nfs nfs rw,nolock 0 0
# After (locking enabled - remove nolock):
server:/export /mnt/nfs nfs rw,hard,intr 0 0Then remount:
sudo mount -o remount /mnt/nfsNote: Some NAS devices or older NFS servers may not support locking. If remounting without nolock causes hangs or errors, see the workaround steps below.
The NFS lock manager requires the rpc.statd and rpc.lockd services to be running:
On systems using systemd (Ubuntu 16.04+, Debian 8+, RHEL/CentOS 7+, Fedora):
# Check status of NFS client services
sudo systemctl status nfs-client.target
sudo systemctl status rpc-statd
# Start and enable the services
sudo systemctl enable rpc-statd
sudo systemctl start rpc-statd
# For some distributions, you may also need:
sudo systemctl enable nfs-lock
sudo systemctl start nfs-lock
# Restart NFS client services to apply
sudo systemctl restart nfs-utilsOn older systems using SysV init:
# Check if services are running
service nfslock status
service rpcbind status
# Start the services
sudo service rpcbind start
sudo service nfslock start
# Enable at boot
sudo chkconfig rpcbind on
sudo chkconfig nfslock onVerify the lock daemon is running:
rpcinfo -p | grep -E 'nlockmgr|status'
# You should see entries for nlockmgr (lockd) and status (statd)NFS locking uses additional ports beyond the standard NFS port (2049). Ensure these are open:
Required ports for NFS locking:
- TCP/UDP 111 (rpcbind/portmapper)
- TCP/UDP 2049 (NFS)
- TCP/UDP 32803 (lockd - may vary)
- TCP/UDP 32769 (statd - may vary)
Check and open ports with firewalld:
# Check current firewall rules
sudo firewall-cmd --list-all
# Add NFS and related services
sudo firewall-cmd --permanent --add-service=nfs
sudo firewall-cmd --permanent --add-service=rpc-bind
sudo firewall-cmd --permanent --add-service=mountd
# Reload firewall
sudo firewall-cmd --reloadCheck and open ports with iptables:
# Allow NFS-related traffic
sudo iptables -A INPUT -p tcp --dport 111 -j ACCEPT
sudo iptables -A INPUT -p udp --dport 111 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 2049 -j ACCEPT
sudo iptables -A INPUT -p udp --dport 2049 -j ACCEPTFor cloud environments (AWS, GCP, Azure):
Check security groups and network ACLs to ensure NFS lock ports are allowed between client and server subnets.
NFSv4 has locking built into the protocol itself, eliminating the need for separate lock daemons:
# Mount using NFSv4 explicitly
sudo mount -t nfs4 server:/export /mnt/nfs
# Or specify version in mount options
sudo mount -t nfs -o vers=4,rw,hard,intr server:/export /mnt/nfsFor /etc/fstab:
server:/export /mnt/nfs nfs4 rw,hard,intr 0 0Verify NFSv4 is being used:
nfsstat -m
# Look for "vers=4" in the outputNote: Both client and server must support NFSv4. Check server compatibility:
# On the NFS server
cat /proc/fs/nfsd/versions
# Should show +4 or +4.1 for NFSv4 supportIf you cannot enable NFS locking (e.g., NAS device limitation, no server access), the most reliable workaround is to work with Git on a local filesystem:
Option 1: Clone to local disk, sync to NFS
# Clone to local filesystem
git clone https://github.com/user/repo.git ~/local-repo
# Work locally, then sync to NFS for backup/sharing
rsync -av --exclude='.git' ~/local-repo/ /mnt/nfs/repo/Option 2: Use git worktree with local storage
# Keep the .git directory on local storage
mkdir -p ~/git-storage/myrepo.git
git clone --bare https://github.com/user/repo.git ~/git-storage/myrepo.git
# Create a worktree on NFS for the files
git -C ~/git-storage/myrepo.git worktree add /mnt/nfs/myrepo mainOption 3: Use symlinks
# Move .git to local storage
mv /mnt/nfs/repo/.git ~/local-git-storage/repo.git
# Create symlink
ln -s ~/local-git-storage/repo.git /mnt/nfs/repo/.gitThis keeps your working files on NFS (for sharing/backup) while Git's internal files remain on a local filesystem that supports proper locking.
You can tell Git to use a different location for its index file using the GIT_INDEX_FILE environment variable:
# Set index to local filesystem
export GIT_INDEX_FILE=/tmp/git-index-$(basename $(pwd))
# Now run Git commands
git status
git add .
git commit -m "message"Create a wrapper script for convenience:
#!/bin/bash
# Save as ~/bin/nfs-git
# Generate unique index path based on repo location
REPO_HASH=$(echo "$PWD" | md5sum | cut -d' ' -f1)
export GIT_INDEX_FILE="/tmp/git-index-$REPO_HASH"
# Run git with all passed arguments
git "$@"Warning: This workaround has significant limitations:
- The index is not shared between machines accessing the same NFS repo
- If /tmp is cleared, you'll lose your staging area
- Concurrent access from multiple machines can still cause issues
- This is a hack, not a proper solution
For production use, prefer moving the repository to local storage.
If you have access to the NFS server, verify the export configuration supports locking:
On the NFS server, check /etc/exports:
cat /etc/exports
# Example entry:
# /export 192.168.1.0/24(rw,sync,no_subtree_check)Ensure these options are NOT set:
- no_auth_nlm - Disables authentication for lock requests
- Consider adding fsid=0 for NFSv4
Apply changes:
sudo exportfs -ra
sudo systemctl restart nfs-serverCheck server-side lock daemon:
sudo systemctl status nfs-server
sudo systemctl status rpc-statd
# Verify lock manager is registered
rpcinfo -p | grep nlockmgrFor NAS devices (Synology, QNAP, etc.):
- Check the NFS settings in the web admin interface
- Look for "Enable NFS lock" or similar option
- Some consumer NAS devices have limited NFS lock support
Understanding NFS Locking Architecture:
NFS file locking has evolved across different versions:
NFSv2 and NFSv3:
- Locking is handled by a separate Network Lock Manager (NLM) protocol
- Requires rpc.lockd and rpc.statd daemons on both client and server
- The statd daemon tracks client state for lock recovery after crashes
- Locking is advisory, not mandatory - processes must cooperate
NFSv4:
- Locking is integrated into the NFS protocol itself
- No separate lock daemon needed
- Uses "leases" - locks automatically expire if the client doesn't renew them
- More robust recovery from network partitions and crashes
Why Git Needs Locks:
Git creates lock files for:
- .git/index.lock - Staging area modifications
- .git/HEAD.lock - HEAD pointer updates
- .git/refs/heads/*.lock - Branch reference updates
- .git/config.lock - Configuration changes
Without functioning locks, concurrent Git operations can corrupt the repository by:
- Writing conflicting data to the index
- Creating inconsistent ref states
- Partially completing multi-file operations
Performance Considerations:
NFS locking can significantly impact Git performance:
- Each lock operation requires a network round-trip to the lock manager
- High-latency connections multiply this overhead
- Git operations that are instant locally can take seconds on NFS
Consider these Git configurations for NFS:
# Reduce operations that need locks
git config core.preloadindex false
git config gc.auto 0 # Disable auto garbage collection
# Increase timeouts
git config http.lowSpeedLimit 0
git config http.lowSpeedTime 999999Container and Docker Considerations:
When using Git in containers with NFS volumes:
# Docker Compose example with NFS
volumes:
nfs_volume:
driver: local
driver_opts:
type: nfs
o: addr=server,rw,hard,intr,nfsvers=4
device: ":/export"For Kubernetes with NFS:
- Consider using PersistentVolumeClaims with local storage for Git operations
- Use init containers to clone repos to emptyDir volumes
- Use sidecar containers for Git sync instead of direct NFS access
Alternative Storage Solutions:
If NFS locking remains problematic:
1. GlusterFS - Distributed filesystem with better POSIX compatibility
2. CephFS - Supports file locking, better for Git workloads
3. SSHFS - FUSE-based, full locking support (but slower)
4. SMB/CIFS - Windows file sharing protocol, often better lock support than NFS
Debugging NFS Lock Issues:
# Check NFS statistics
nfsstat -c # Client statistics
nfsstat -s # Server statistics (on server)
# Monitor lock operations
rpcdebug -m nlm # Enable NLM debugging (requires root)
dmesg | grep -i nfs # Check kernel messages
# Test lock functionality
perl -e 'use Fcntl qw(:flock); open(F,">","/mnt/nfs/test.lock") or die; flock(F,LOCK_EX) or die "lock failed: $!"; print "locked"; sleep 30;'Security Implications:
The nolock mount option is sometimes used intentionally:
- Read-only mounts don't need locking
- Some security policies disable locking to reduce attack surface
- NFS lock manager has had historical security vulnerabilities
If locking is disabled for security reasons, coordinate with your system administrator before enabling it.
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