starred/gitea-mirror

Fork 0

mirror of https://github.com/RayLabsHQ/gitea-mirror.git synced 2026-04-25 07:15:57 +03:00

[GH-ISSUE #20] Error: [ERROR] SQLiteError: attempt to write a readonly database #7

New issue

Closed

opened 2026-02-27 15:54:30 +03:00 by kerem · 6 comments

kerem commented

2026-02-27 15:54:30 +03:00

Owner

Originally created by @kylepyke on GitHub (May 27, 2025).
Original GitHub issue: https://github.com/RayLabsHQ/gitea-mirror/issues/20

I can't seem to get past this permissions error to open/write to the database, and there isn't much in the docs describing necessary database permissions.

Originally created by @kylepyke on GitHub (May 27, 2025). Original GitHub issue: https://github.com/RayLabsHQ/gitea-mirror/issues/20 I can't seem to get past this permissions error to open/write to the database, and there isn't much in the docs describing necessary database permissions.

kerem

2026-02-27 15:54:30 +03:00

closed this issue
added the
question
label

kerem commented

2026-02-27 15:54:31 +03:00

Author

Owner

@kylepyke commented on GitHub (May 28, 2025):

I had to chmod 777 the database folder AND the folder where the database resides to get past this error. Any advice on what the permissions need to be here?

@kylepyke commented on GitHub (May 28, 2025): I had to `chmod 777` the database folder AND the folder where the database resides to get past this error. Any advice on what the permissions need to be here?

kerem commented

2026-02-27 15:54:31 +03:00

Author

Owner

@arunavo4 commented on GitHub (May 28, 2025):

Hi @kylepyke,

Thanks for reporting this issue! You're absolutely right about the permission requirements, and I appreciate you sharing the solution that worked for you.

The Issue

This SQLite permission error occurs when running Gitea Mirror directly on your system (not in Docker). SQLite requires:

Read/write access to the database file itself (data/gitea-mirror.db)
Write access to the directory containing the database (data/ folder) - this is needed for SQLite's temporary files, WAL files, and journal files

Why `chmod 777` Worked (But Isn't Recommended)

Your chmod 777 solution worked because it gave read/write/execute permissions to everyone (owner, group, and others). While this fixes the immediate issue, it's not recommended for security reasons as it makes the database accessible to all users on the system.

Documentation Update

I've added a section to the README specifically addressing this issue for users who choose to run the application directly instead of using Docker. You can find it in the "Database Permissions for Direct Installation" section.

Recommendation

For production use, I strongly recommend using Docker or Docker Compose as it provides:

Proper permission handling out of the box
Consistent environment across different systems
Better security isolation
Easier updates and maintenance

Let me know if you have any other questions or if the suggested solutions work for you!

@arunavo4 commented on GitHub (May 28, 2025): Hi @kylepyke, Thanks for reporting this issue! You're absolutely right about the permission requirements, and I appreciate you sharing the solution that worked for you. ## The Issue This SQLite permission error occurs when running Gitea Mirror **directly on your system** (not in Docker). SQLite requires: 1. **Read/write access** to the database file itself (`data/gitea-mirror.db`) 2. **Write access** to the directory containing the database (`data/` folder) - this is needed for SQLite's temporary files, WAL files, and journal files ## Recommended Solutions ### Option 1: Use Docker (Recommended) The easiest way to avoid this issue entirely is to use Docker, which handles all permissions automatically: ```bash # Using Docker Compose (recommended) docker compose up -d # Or using Docker directly docker run -d -p 4321:4321 \ -v gitea-mirror-data:/app/data \ ghcr.io/arunavo4/gitea-mirror:latest ``` **Why Docker doesn't have this issue:** - The container runs with a dedicated `gitea-mirror` user that owns the `/app/data` directory - Permissions are set correctly during the Docker image build process - Volume mounts are handled by Docker with appropriate permissions ### Option 2: Fix Permissions for Direct Installation If you prefer to run the application directly, here's the proper way to set permissions (more secure than `chmod 777`): ```bash # Ensure the data directory exists and has proper permissions mkdir -p data chmod 755 data # If the database file already exists, ensure it's writable chmod 644 data/gitea-mirror.db # Make sure the user running the application owns the data directory chown -R $(whoami) data/ ``` ## Why `chmod 777` Worked (But Isn't Recommended) Your `chmod 777` solution worked because it gave read/write/execute permissions to everyone (owner, group, and others). While this fixes the immediate issue, it's not recommended for security reasons as it makes the database accessible to all users on the system. ## Documentation Update I've added a section to the README specifically addressing this issue for users who choose to run the application directly instead of using Docker. You can find it in the "Database Permissions for Direct Installation" section. ## Recommendation For production use, I strongly recommend using Docker or Docker Compose as it provides: - Proper permission handling out of the box - Consistent environment across different systems - Better security isolation - Easier updates and maintenance Let me know if you have any other questions or if the suggested solutions work for you!

kerem commented

2026-02-27 15:54:31 +03:00

Author

Owner

@kylepyke commented on GitHub (May 28, 2025):

I am using docker and still receiving this error. I deployed gitea-mirror using docker compose via Portainer.

EDIT: Aha, I think I see the issue:

The container runs with a dedicated gitea-mirror user that owns the /app/data directory

I'm passing a bind mount in the docker compose, which is not used by the gitea-mirror user.

@kylepyke commented on GitHub (May 28, 2025): I am using docker and still receiving this error. I deployed gitea-mirror using docker compose via Portainer. EDIT: Aha, I think I see the issue: >The container runs with a dedicated gitea-mirror user that owns the /app/data directory I'm passing a bind mount in the docker compose, which is not used by the `gitea-mirror` user.

kerem commented

2026-02-27 15:54:31 +03:00

Author

Owner

@arunavo4 commented on GitHub (May 28, 2025):

@kylepyke So you can either

Switch to named volumes (recommended)
Fix the bind mount permissions with sudo chown -R 1001:1001 /host/path/to/data

Added a section to readme for people having this issue in the future

@arunavo4 commented on GitHub (May 28, 2025): @kylepyke So you can either 1. Switch to named volumes (recommended) 2. Fix the bind mount permissions with `sudo chown -R 1001:1001 /host/path/to/data` Added a section to [readme](https://github.com/arunavo4/gitea-mirror#docker-volume-types-and-permissions) for people having this issue in the future

kerem commented

2026-02-27 15:54:31 +03:00

Author

Owner

@kylepyke commented on GitHub (May 28, 2025):

Thank you, and really appreciate your work on this project!!

Will I be able to switch to named volumes, and keep my current database with all of my synced repositories? I assume no...

@kylepyke commented on GitHub (May 28, 2025): Thank you, and really appreciate your work on this project!! Will I be able to switch to named volumes, and keep my current database with all of my synced repositories? I assume no...

kerem commented

2026-02-27 15:54:31 +03:00

Author

Owner

@arunavo4 commented on GitHub (May 28, 2025):

@kylepyke take a backup by simply accessing the file and then replace it after you have made a new deployment with named volume

@arunavo4 commented on GitHub (May 28, 2025): @kylepyke take a backup by simply accessing the file and then replace it after you have made a new deployment with named volume

kerem referenced this issue

2026-02-27 15:55:06 +03:00

[PR #7] [CLOSED] Migrate project to Bun runtime #95