starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Data Persistence to CIFS #3111

New issue

Closed

opened 2026-02-28 03:18:24 -05:00 by deekerman · 12 comments

deekerman commented

2026-02-28 03:18:24 -05:00

Owner

Originally created by @chrisfore on GitHub (Feb 7, 2024).

⚠️ Please verify that this question has NOT been raised before.

I checked and didn't find similar issue

🛡️ Security Policy

I agree to have read this project Security Policy

📝 Describe your problem

I have used a volume mount to save the /data folder to a cifs mount. The container boots without issue and the kuma.db file and a few other folders are written to the mount. When I redeploy the container with the same mount point, all configuration (monitors, admin settings, notifications) are lost/not persistent.

📝 Error Message(s) or Log

no messages in the error.log

🐻 Uptime-Kuma Version

1.23.10

💻 Operating System and Arch

ubuntu 22.04 with docker engine

🌐 Browser

brave

🖥️ Deployment Environment

Runtime: ubuntu 22.04 - Docker version 25.0.1, build 29cf629
Database:
Filesystem used to store the database on: cifs to all flash nas
number of monitors: 8

Originally created by @chrisfore on GitHub (Feb 7, 2024). ### ⚠️ Please verify that this question has NOT been raised before. - [X] I checked and didn't find similar issue ### 🛡️ Security Policy - [X] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### 📝 Describe your problem I have used a volume mount to save the /data folder to a cifs mount. The container boots without issue and the kuma.db file and a few other folders are written to the mount. When I redeploy the container with the same mount point, all configuration (monitors, admin settings, notifications) are lost/not persistent. ### 📝 Error Message(s) or Log no messages in the error.log ### 🐻 Uptime-Kuma Version 1.23.10 ### 💻 Operating System and Arch ubuntu 22.04 with docker engine ### 🌐 Browser brave ### 🖥️ Deployment Environment - Runtime: ubuntu 22.04 - Docker version 25.0.1, build 29cf629 - Database: - Filesystem used to store the database on: cifs to all flash nas - number of monitors: 8

deekerman

2026-02-28 03:18:24 -05:00

closed this issue
added the
A:deployment

help
labels

deekerman commented

2026-02-28 03:18:27 -05:00

Author

Owner

@chrisfore commented on GitHub (Feb 7, 2024):

monitor_logs.txt

@chrisfore commented on GitHub (Feb 7, 2024): [monitor_logs.txt](https://github.com/louislam/uptime-kuma/files/14196892/monitor_logs.txt)

deekerman commented

2026-02-28 03:18:27 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Feb 7, 2024):

Foremost, please don't use CIFS (or other networked storage for that matter) to store your SQLite database, as documented in our installation guide.
You are risking db-corruption issues by doing so.

See

our docs https://github.com/louislam/uptime-kuma/wiki/%F0%9F%94%A7-How-to-Install#-docker
a specific excerpt on using CIFS and sqlite https://sqlite-users.sqlite.narkive.com/PkF3Wqkw/how-to-make-sqlite-run-safely-on-cifs-mounted-file-system

However, your specific issue is unrelated. (TBH I don't know what you are asking…)
Not mounting persistently is not something that we support.
I have no idea how CIFS mounting works, but I assume it be that said storage is either deleted on pod/container exit or not restored correctly?
Have you tried if your configuration is indeed persistent?
=> please refer to the CIFS docs/user forum on how to do so (assuming you accept the corruption risk) ^^

@CommanderStorm commented on GitHub (Feb 7, 2024): Foremost, please don't use CIFS (or other networked storage for that matter) to store your SQLite database, as documented in our installation guide. You are risking db-corruption issues by doing so. See - our docs https://github.com/louislam/uptime-kuma/wiki/%F0%9F%94%A7-How-to-Install#-docker - a specific excerpt on using CIFS and sqlite https://sqlite-users.sqlite.narkive.com/PkF3Wqkw/how-to-make-sqlite-run-safely-on-cifs-mounted-file-system However, your specific issue is unrelated. (TBH I don't know what you are asking…) Not mounting persistently is not something that we support. I have no idea how CIFS mounting works, but I assume it be that said storage is either deleted on pod/container exit or not restored correctly? Have you tried if your configuration is indeed persistent? => please refer to the CIFS docs/user forum on how to do so (assuming you accept the corruption risk) ^^

deekerman commented

2026-02-28 03:18:27 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Feb 7, 2024):

I closed this because I don't think that we can help you with CIFS mounting issues and that this is better asked in a CIFS specific forum
=> with people who know more about your issue.

If this turns out to be an issue on our end (or something that we can help with), please feel free to reach out ^^

@CommanderStorm commented on GitHub (Feb 7, 2024): I closed this because I don't think that we can help you with CIFS mounting issues and that this is better asked in a CIFS specific forum => with people who know more about your issue. If this turns out to be an issue on our end (or something that we can help with), please feel free to reach out ^^

deekerman commented

2026-02-28 03:18:27 -05:00

Author

Owner

@chrisfore commented on GitHub (Feb 7, 2024):

I am asking where is data stored, is everything (notification/monitor settings authentication settings) in the same kuma.db file? I am trying to make these settings persistent across container tear down and redeployment. Even using the recommended settings (storage on local host) these settings were lost when I removed and deployed the container.

@chrisfore commented on GitHub (Feb 7, 2024): I am asking where is data stored, is everything (notification/monitor settings authentication settings) in the same kuma.db file? I am trying to make these settings persistent across container tear down and redeployment. Even using the recommended settings (storage on local host) these settings were lost when I removed and deployed the container.

deekerman commented

2026-02-28 03:18:27 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Feb 7, 2024):

Yes, all data is stored in the same database.
How are you binding your volumes?

@CommanderStorm commented on GitHub (Feb 7, 2024): Yes, all data is stored in the same database. How are you binding your volumes?

deekerman commented

2026-02-28 03:18:27 -05:00

Author

Owner

@chrisfore commented on GitHub (Feb 7, 2024):

Thank you for the help. I am using the following in my compose file... the commented out versions are different mount points I have tried/used. (I added the ! to avoid formatting errors in this comment)

version: '3.3'
services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    container_name: monitor
    restart: unless-stopped
    volumes:
    - /home/cfore/kuma:/app/data
!#    - ./data:app/data
!#    - /var/run/docker.sock:/var/run/docker.sock
!#    - /mnt/docker/kuma:/app/data
    ports:
    - 13001:3001
    environment:
    - PGID=999
!#    - PUID=1000
    - DATA_DIR=/home/cfore/kuma/uptime-kuma-data

@chrisfore commented on GitHub (Feb 7, 2024): Thank you for the help. I am using the following in my compose file... the commented out versions are different mount points I have tried/used. (I added the ! to avoid formatting errors in this comment) ```yaml version: '3.3' services: uptime-kuma: image: louislam/uptime-kuma:latest container_name: monitor restart: unless-stopped volumes: - /home/cfore/kuma:/app/data !# - ./data:app/data !# - /var/run/docker.sock:/var/run/docker.sock !# - /mnt/docker/kuma:/app/data ports: - 13001:3001 environment: - PGID=999 !# - PUID=1000 - DATA_DIR=/home/cfore/kuma/uptime-kuma-data

deekerman commented

2026-02-28 03:18:27 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Feb 7, 2024):

You set DATA_DIR to store /home/cfore/kuma/uptime-kuma-data, but are persisting app/data and /app/data ^^

@CommanderStorm commented on GitHub (Feb 7, 2024): You set `DATA_DIR` to store `/home/cfore/kuma/uptime-kuma-data`, but are persisting `app/data` and `/app/data` ^^

deekerman commented

2026-02-28 03:18:27 -05:00

Author

Owner

@chrisfore commented on GitHub (Feb 7, 2024):

What updates would you make to the yml file to persistent the data at the /home/cfore/kuma/uptime-kuma-data location?

Thanks again for the help, and hoping this helps others in the future.

@chrisfore commented on GitHub (Feb 7, 2024): What updates would you make to the yml file to persistent the data at the /home/cfore/kuma/uptime-kuma-data location? Thanks again for the help, and hoping this helps others in the future.

deekerman commented

2026-02-28 03:18:27 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Feb 7, 2024):

Do you need this location to be inside or outside the container?
DATA_DIR controls where the data directory is INSIDE, while the mounts control where directories from are OUTSIDE the container.

@CommanderStorm commented on GitHub (Feb 7, 2024): Do you need this location to be inside or outside the container? `DATA_DIR` controls where the data directory is INSIDE, while the mounts control where directories from are OUTSIDE the container.

deekerman commented

2026-02-28 03:18:27 -05:00

Author

Owner

@chrisfore commented on GitHub (Feb 7, 2024):

I would like the data outside of the container so when the container is deleted and recreated (like an upgrade) the data is persistent. I removed the DATA_DIR the data inside is then placed on the volume location. When I delete the container and create a new one (with the same volume) the database is empty again even though the kuna.db file was still left behind from the previous container.

@chrisfore commented on GitHub (Feb 7, 2024): I would like the data outside of the container so when the container is deleted and recreated (like an upgrade) the data is persistent. I removed the DATA_DIR the data inside is then placed on the volume location. When I delete the container and create a new one (with the same volume) the database is empty again even though the kuna.db file was still left behind from the previous container.

deekerman commented

2026-02-28 03:18:27 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Feb 7, 2024):

I am unsure what docker compose file you are currently working with.
Could you attach your current file?

Please also ls -lah DIRECTORY_OUTSIDE_CONTAINER on the volume outside the container?
It seems like you changed the PGID and PUID variables ⇒ can said container write to its data directory?

@CommanderStorm commented on GitHub (Feb 7, 2024): I am unsure what docker compose file you are currently working with. Could you attach your current file? Please also `ls -lah DIRECTORY_OUTSIDE_CONTAINER` on the volume outside the container? It seems like you changed the `PGID` and `PUID` variables ⇒ can said container [write to its data directory?](https://github.com/louislam/uptime-kuma/wiki/Troubleshooting)

deekerman commented

2026-02-28 03:18:27 -05:00

Author

Owner

@chrisfore commented on GitHub (Feb 8, 2024):

So I have this working and I am sharing the findings for anyone in the future with similar issues.

As @CommanderStorm pointed out the DATA_DIR create an ephemeral location INSIDE of the container for the data to be stored. To store information OUTSIDE of the container I use the volume statement below. I accept the liability of using this location on a NAS and it is working for me (for now). This location could be on the docker host OUTSIDE of the container if you prefer. I am using two volume mounts, #2 allows me to monitor the docker host using the configuration in the GUI. I am NOT using the DATA_DIR to achieve data persistence across upgrade/redeploy

volumes:
- /mnt/docker/kuma:/app/data #1 This moves the data to a mount location on my physical host OUTSIDE of the container
- /var/run/docker.sock:/var/run/docker.sock #2 This allows me to monitor the docker host

Thank you for all the help and for this AMAZING project!!!

@chrisfore commented on GitHub (Feb 8, 2024): So I have this working and I am sharing the findings for anyone in the future with similar issues. As @CommanderStorm pointed out the DATA_DIR create an ephemeral location INSIDE of the container for the data to be stored. To store information OUTSIDE of the container I use the volume statement below. I accept the liability of using this location on a NAS and it is working for me (for now). This location could be on the docker host OUTSIDE of the container if you prefer. I am using two volume mounts, #2 allows me to monitor the docker host using the configuration in the GUI. I am NOT using the DATA_DIR to achieve data persistence across upgrade/redeploy volumes: - /mnt/docker/kuma:/app/data #1 This moves the data to a mount location on my physical host OUTSIDE of the container - /var/run/docker.sock:/var/run/docker.sock #2 This allows me to monitor the docker host Thank you for all the help and for this AMAZING project!!!