How to fix fatal: cannot create pack: Too many open files in Git

GitINTERMEDIATEMEDIUMUpdated Dec 6, 2025· 148 views

The 'fatal: cannot create pack: Too many open files' error occurs when Git exceeds the operating system's limit on the number of files a process can open simultaneously. This commonly happens during garbage collection, push, fetch, or repack operations on large repositories with many loose objects.

Quick fix

Fixes fatal: cannot create pack: Too many open files

# Check soft limit (current limit)
ulimit -n

# Check hard limit (maximum allowed)
ulimit -Hn

# View all limits
ulimit -a
  1. Check current file descriptor limits
  2. Temporarily increase the file limit
  3. Make the change permanent on Linux
  4. Configure limits for systemd services
git — error
# Check soft limit (current limit)
ulimit -n
# Check hard limit (maximum allowed)
ulimit -Hn
# View all limits
ulimit -a
fatal: cannot create pack: Too many open files

What this error means

The "fatal: cannot create pack: Too many open files" error indicates that Git has hit the EMFILE (error: maximum files) limit imposed by the operating system. Every process on Unix-like systems has a limit on how many file descriptors it can hold open at once, controlled by the `ulimit -n` setting. Git operations like `git gc`, `git push`, `git fetch`, and `git repack` need to open many files simultaneously, especially when working with loose objects or multiple packfiles. By default, Linux systems allow 1024 open files per process, while macOS defaults to an even lower 256. When Git needs to process more objects than this limit allows, the operation fails with this error. The most common trigger is Git's automatic garbage collection (`git gc --auto`), which runs automatically during push and fetch operations. When a repository accumulates approximately 6,700 loose objects, Git attempts to pack them, requiring file handles for each object. If your ulimit is below this threshold, the garbage collection will fail.

Typical symptoms

  • Git push or fetch fails with 'fatal: cannot create pack: Too many open files'
  • Git gc or git repack commands fail with 'Too many open files' error
  • Error appears: 'error: cannot create pipe for ssh: Too many open files'
  • Operations fail with 'fatal: unable to fork' alongside file limit errors
  • Large repositories fail where smaller ones succeed
  • Error occurs intermittently as repository accumulates more loose objects
  • CI/CD pipelines fail during Git operations on large repositories
  • macOS users experience the error more frequently due to lower default limits

Common causes

  1. System ulimit for open files is too low (default 1024 on Linux, 256 on macOS)
  2. Repository has accumulated thousands of loose objects triggering git gc --auto
  3. Large number of packfiles in the repository exhausting file descriptors
  4. Multiple Git operations running concurrently on the same repository
  5. Running Git in a containerized environment with restricted file limits
  6. Git repack operation on repository with extensive history
  7. System-wide file descriptor limit (fs.file-max) is too low
  8. Running as a service account with reduced resource limits

How to fix "fatal: cannot create pack: Too many open files"

1Check current file descriptor limits

First, check your current ulimit settings to understand the constraint:

bash
# Check soft limit (current limit)
ulimit -n

# Check hard limit (maximum allowed)
ulimit -Hn

# View all limits
ulimit -a

The soft limit is what your processes actually use, while the hard limit is the maximum you can set without root privileges. On most Linux systems, you'll see 1024 as the default soft limit.

2Temporarily increase the file limit

For an immediate fix, increase the limit in your current shell session:

bash
# Increase to 8192 (common safe value)
ulimit -n 8192

# Or increase to 65536 for very large repositories
ulimit -n 65536

# Then retry your Git operation
git push origin main

Note: You can only increase up to the hard limit. If you need more, you'll need to modify system configuration files with root access.

3Make the change permanent on Linux

To persist the change across sessions and reboots, edit the limits configuration:

bash
# Edit the limits configuration file
sudo nano /etc/security/limits.conf

# Add these lines at the end (replace 'username' with your user or use '*' for all users)
username soft nofile 65536
username hard nofile 65536

# Or for all users:
* soft nofile 65536
* hard nofile 65536

You may also need to ensure PAM is configured to apply these limits:

bash
# Check if pam_limits is enabled
grep pam_limits /etc/pam.d/common-session

# If not present, add:
# session required pam_limits.so

Log out and back in for changes to take effect.

4Configure limits for systemd services

If Git is running as a systemd service (like in CI/CD), configure limits in the service file:

bash
# Edit or create a service override
sudo systemctl edit your-git-service

# Add these lines:
[Service]
LimitNOFILE=65536

Or modify the system-wide systemd defaults:

bash
# Edit systemd configuration
sudo nano /etc/systemd/system.conf

# Add or modify:
DefaultLimitNOFILE=65536

# Reload systemd
sudo systemctl daemon-reexec
5Adjust Git garbage collection threshold

If you cannot modify system limits, configure Git to run garbage collection before hitting the file limit:

bash
# Lower the gc.auto threshold to trigger GC earlier
# Set to a value below your ulimit -n
git config --global gc.auto 200

# Or disable automatic garbage collection entirely
git config --global gc.auto 0

With automatic GC disabled, you'll need to manually run garbage collection periodically:

bash
# Run manual garbage collection
git gc

# Or more aggressive cleanup
git gc --aggressive --prune=now
6Run manual garbage collection to reduce loose objects

If the error has already occurred, manually clean up the repository:

bash
# First, temporarily increase ulimit if possible
ulimit -n 8192

# Run garbage collection
git gc

# Or use git repack with specific options
git repack -a -d --depth=250 --window=250

If you can't increase ulimit, try this workaround:

bash
# Push your commits to remote
git push origin main

# Delete the local repository
cd ..
rm -rf your-repo

# Clone fresh (without loose objects)
git clone https://github.com/user/your-repo.git
7Configure pack memory and size limits

For large repositories, configure Git's pack settings to reduce resource usage:

bash
# Limit memory used during packing (100MB)
git config --global pack.windowMemory "100m"

# Limit pack file size
git config --global pack.packSizeLimit "100m"

# Reduce threading to limit concurrent file access
git config --global pack.threads 1

# Reduce delta cache size
git config --global pack.deltaCacheSize "100m"

These settings trade performance for lower resource usage, which can help avoid the file limit error.

8Fix on macOS

macOS has a particularly low default limit (256). To fix:

bash
# Check current limit
ulimit -n

# Temporarily increase (per session)
ulimit -n 4096

# Make permanent by adding to shell profile
echo 'ulimit -n 4096' >> ~/.zshrc
# Or for bash:
echo 'ulimit -n 4096' >> ~/.bash_profile

# Source the profile
source ~/.zshrc

For system-wide changes on modern macOS (10.10+):

bash
# Create or edit launchd configuration
sudo nano /Library/LaunchDaemons/limit.maxfiles.plist

Add this content:

xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>Label</key>
    <string>limit.maxfiles</string>
    <key>ProgramArguments</key>
    <array>
      <string>launchctl</string>
      <string>limit</string>
      <string>maxfiles</string>
      <string>65536</string>
      <string>65536</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
  </dict>
</plist>

Then load it:

bash
sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
9Fix in Docker containers

Docker containers often have restricted limits. Configure them in your Docker setup:

bash
# Run container with increased ulimit
docker run --ulimit nofile=65536:65536 your-image

# Or in docker-compose.yml:
services:
  your-service:
    ulimits:
      nofile:
        soft: 65536
        hard: 65536

For Kubernetes:

yaml
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: git-container
    securityContext:
      # Note: requires privileged mode or proper security policies
    resources:
      limits:
        # Some Kubernetes setups allow ulimit configuration

You may need to configure the underlying nodes or use init containers to set limits.

Advanced notes

### Understanding File Descriptor Limits

Unix-like systems have two levels of file limits:
- Per-process limit (ulimit -n): Maximum files a single process can open. This is what Git hits.
- System-wide limit (fs.file-max): Total files all processes combined can open.

Check system-wide limit:

bash
cat /proc/sys/fs/file-max
# Current usage
cat /proc/sys/fs/file-nr

If the system-wide limit is also low, increase it:

bash
# Temporary
sudo sysctl -w fs.file-max=2097152

# Permanent (add to /etc/sysctl.conf)
fs.file-max = 2097152

### Why 6,700 Objects Triggers the Error

Git's gc.auto defaults to 6700, meaning automatic garbage collection runs when loose objects exceed this count. During GC, Git needs to open file handles for:
- Each loose object being packed
- The new packfile being written
- Index files
- Temporary files

With overhead, processing 6,700 objects can require 7,000+ file handles, exceeding the default 1024 limit.

### Git Bash on Windows

Git Bash has its own ulimit constraints:

bash
# Maximum on Git Bash is around 3200
ulimit -n 3200

# Note: Cannot lower limit once raised in same session

For Windows native Git (cmd/PowerShell), file limits work differently and are generally higher by default.

### Diagnosing with strace

To see exactly which files Git is trying to open:

bash
strace -e open,openat -f git gc 2>&1 | tail -50

This helps identify if Git is properly closing files or if there's a file descriptor leak.

### CI/CD Specific Considerations

Many CI systems run with reduced limits:
- GitHub Actions: Generally has high limits, but self-hosted runners may not
- GitLab CI: Configurable via runner settings
- Jenkins: Depends on how the agent is launched; configure in systemd service file
- CircleCI: May need resource_class adjustment

Always verify limits in CI:

yaml
# Example GitHub Actions step
- name: Check ulimit
  run: ulimit -a

Frequently asked questions

What does "fatal: cannot create pack: Too many open files" mean?
The "fatal: cannot create pack: Too many open files" error indicates that Git has hit the EMFILE (error: maximum files) limit imposed by the operating system. Every process on Unix-like systems has a limit on how many file descriptors it can hold open at once, controlled by the ulimit -n setting. Git operations like git gc, git push, git fetch, and git repack need to open many files simultaneously, especially when working with loose objects or multiple packfiles.
How do I fix "fatal: cannot create pack: Too many open files"?
The 'fatal: cannot create pack: Too many open files' error occurs when Git exceeds the operating system's limit on the number of files a process can open simultaneously. This commonly happens during garbage collection, push, fetch, or repack operations on large repositories with many loose objects.
What causes "fatal: cannot create pack: Too many open files"?
System ulimit for open files is too low (default 1024 on Linux, 256 on macOS) Repository has accumulated thousands of loose objects triggering git gc --auto Large number of packfiles in the repository exhausting file descriptors
Is the "fatal: cannot create pack: Too many open files" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading