Common Issues and Troubleshooting for Self-Hosted Code Repositories (Git / SVN)

When self-hosted code repositories (such as GitLab, Gitea, SVN, etc.) encounter issues, common symptoms include failed push/pull operations, inaccessible web pages, or sudden disk full errors. Essentially, it is a combination of a “Web Application + Storage + SSH/HTTP Service,” so troubleshooting should be performed in layers.

Layering: Identify Which Segment Is Failing

① Service Status

# Check if the service is running (commands vary by solution)
systemctl status gitlab-runsvdir      # GitLab omnibus installation
systemctl status gitea
systemctl status svnserve

# Check ports
ss -lntp | grep -E '80|443|22|3000|8080'

# Check logs
journalctl -u gitea --no-pager | tail -50
tail -50 /var/log/gitlab/nginx/gitlab_error.log

Common Causes for Inaccessible Web Pages

# ① Service not started or still starting up (GitLab starts slowly)
systemctl status gitlab-runsvdir

# ② Port conflict (built-in nginx conflicts with system nginx)
ss -lntp | grep :80
# If system nginx is already occupying port 80, adjust one of them

# ③ Insufficient memory (GitLab has high memory requirements)
free -m
# Startup may fail or be very slow if memory is insufficient

“Built-in nginx competing with existing nginx for port 80” is a very common conflict, especially when installing repository services on servers that are already hosting websites.

# Solution: Let the repository service use a different port, and use the existing nginx as a reverse proxy in front
ss -lntp | grep -E ':80|:8080|:3000'

② Push/Pull Failures via SSH

This is the type of issue most easily misdiagnosed: the web page is normal, HTTP cloning works, but SSH fails.

# ① Test SSH connectivity
ssh -T -v git@repository-domain

# ② Confirm SSH port (specify if not 22)
ssh -T -p port git@repository-domain

# ③ View detailed handshake process (most useful)
ssh -vvv git@repository-domain

# Specify port on client side (~/.ssh/config)
Host git.example.com
    Port 2222
    User git
    IdentityFile ~/.ssh/id_ed25519

# Fix key permissions
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519

③ HTTP(S) Clone Failures

# ① Direct test
git clone https://git.example.com/group/repo.git

# ② Check HTTP status code
curl -I https://git.example.com/group/repo.git

# ③ Verify reverse proxy configuration (if nginx is in front)
# Key points: request body size limit, timeout
grep -E 'client_max_body_size|proxy_read_timeout' /etc/nginx/conf.d/*.conf

A High-Frequency Issue: Large File Push Failure

error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413

# Nginx needs to increase the request body limit
client_max_body_size 500m;

nginx -t && nginx -s reload

413 errors are very common in self-hosted repositories: default limits are usually small, while repository pushes can involve large packages. Since the error message explicitly states 413, it is easy to identify.

④ Disk Issues (High-Frequency Fault for Repository Services)

Repositories grow continuously, and disk full is the most common fault.

df -h
df -i                  # inodes (for many small files)

# Find directories with large usage
du -sh /var/opt/gitlab/* 2>/dev/null | sort -rh | head
du -sh /var/lib/gitea/* 2>/dev/null | sort -rh | head

Repository-Specific Disk Usage Sources

# Clean logs (GitLab has built-in commands)
gitlab-ctl clean-logs 2>/dev/null || journalctl --vacuum-size=500M

# Clean old CI artifacts and backups (according to actual policies)

⑤ Backups (Do Not Forget)

# GitLab built-in backup command (omnibus installation)
gitlab-backup create
# Backup files are stored in /var/opt/gitlab/backups/ by default

# Crucial: Backups must be transferred off-site
rsync -avz /var/opt/gitlab/backups/ root@backup-server:/backup/gitlab/

# Gitea
# Use gitea dump or directly backup data directory and database

Backups must also be verified for recoverability and stored off-site. Code repositories are core assets, and the cost of losing them is high.

Decision Tree

Repository Service Abnormal
├─ Web Page Unavailable
│  ├─ Service not started / slow startup → Check status and logs
│  ├─ Port Conflict (80 occupied)       → Change port or use reverse proxy
│  └─ Insufficient Memory              → Check free -m
├─ HTTP Clone Failed
│  ├─ 413 Error                        → Adjust client_max_body_size ← High Frequency
│  └─ Authentication Failed            → Check account and token
├─ SSH Clone Failed (Web Normal)
│  ├─ Port Not Allowed / Non-22 Not Specified → Check and configure
│  ├─ Permission Denied                → Add SSH key
│  └─ Key Permissions Too Broad        → chmod 600
└─ Various Operations Failed
   └─ Check Disk and inodes first ← High-frequency fault for repository services

Scenario Walkthrough: Code Repository Migrated to New Machine, No One Can Push

Symptom: After migrating a self-hosted code repository to a new server,
code checkout works normally, but everyone’s push fails. The error message looks like a permission issue.

1. First, determine the category of the error →
   Read access is normal, write access fails, indicating authentication passed and the issue lies with write permissions.
   This immediately rules out credential issues.
2. Verify the ownership of repository files →
   Synchronization was executed under a different account during migration, resulting in file ownership not matching the account used by the repository service.
3. Simultaneously confirm if directory permissions allow writing →
   Even if permissions are open, incorrect ownership renders them useless; both must be checked together.
4. Check which protocol is being used for access →
   Different protocols follow different paths and have different permission models; misconfiguration manifests as the same failure.
5. Correct ownership and permissions →
   Align with the account actually used by the repository service.
6. Have each user perform an actual push to verify →
   Do not just verify one account; ensure all users can operate normally.

# Determine which account the repository service actually uses
ps -eo user,cmd | grep -E 'git|svn' | head

# Check ownership and permissions together
ls -ld /repo-directory
ls -l /repo-directory | head -5

# Align ownership
chown -R service-account:service-account /repo-directory

# Verify configuration corresponding to the access method
grep -rIn 'svnserve|git-daemon|ssh://' /repo-config-or-client-config 2>/dev/null | head

Root Cause: Ownership was not aligned with the account actually used by the repository service during migration.
Read operations are insensitive to ownership, while write operations expose it—hence the symptom is “can read but cannot write.”

Two Key Takeaways:

• “Can read but cannot write” usually points to ownership and permissions, not credentials.
  Authentication issues typically manifest as complete access denial, not just write failures.
• After migration, require all users to verify functionality.
  Passing a test with one account does not guarantee everything is normal; permission-related differences often vary by user.

8 Common Pitfalls

1. Built-in nginx competing with existing services for ports: Check who occupies port 80 before installation.
2. Large file push 413 error: Request body limits are small by default.
3. SSH port changed but client not synchronized: Manifests as timeouts.
4. Key permissions too broad: SSH refuses to use them.
5. Ignoring disk space: Disk full is very common for repository services.
6. Not cleaning logs and build artifacts: They grow very quickly.
7. Backups only on local machine: Core assets must be stored off-site.
8. Deploying with insufficient memory: Some repository services have high memory requirements.

Real Customer Feedback (From Cloud Marketplace Reviews and Consultations for Similar Products)

The following excerpts are taken from real buyer reviews and consultations for similar operations and maintenance services on Alibaba Cloud / Tencent Cloud / Huawei Cloud Marketplaces (service providers include this store and peers, provided solely for reference of real feedback, not fictitious tickets from this site):

10***77 2022-09-19 5.0 Affordable Price | Skilled Technology | Patient and Professional Received filing rectification notice, found this service exactly then, handled quickly 10***49 2022-04-12 5.0 On-time Delivery | Affordable Price | Skilled Technology Needed rectification, fast configuration, good

b****4 Rating: 5.0 Points 2025-06-23 16:57 b****4 Rating: 5.0 Points 2025-06-23 16:56 Jian****Wei Rating: 5.0 Points 2021-01-20 15:03 Technology is awesome! Speed is very fast! It turned out to be Baidu global hijacking caused by a trojan!!!! 1 f****u Rating: 5.0 Points 2021-01-02 20:43 Thanks for assisting in maintaining Yuncai’s normal operation. 1****1 Rating: 5.0 Points 2020-11-20 10:03 Consistently good service as always 1****1 Rating: 5.0 Points 2020-11-17 09:13 Thanks for the consistently good service. 1****1 Rating: 5.0 Points 2020-09-25 15:42 Many thanks. 1****1 Rating: 5.0 Points 2020-08-24 15:34 Many thanks to your company’s technical staff 1****1 Rating: 5.0 Points 2020-07-24 09:49 Many thanks! 1