starred/ProxmoxVE
1
0
Fork 0
mirror of https://github.com/community-scripts/ProxmoxVE.git synced 2026-02-05 00:29:55 +03:00
Code Issues 13 Packages Projects Releases 10 Wiki Activity

Karakeep: Update broken when using custom data directory #1349

New Issue
Closed
opened 2026-02-05 00:26:31 +03:00 by OVERLORD · 3 comments
OVERLORD commented 2026-02-05 00:26:31 +03:00
Owner
Copy Link

Originally created by @Zuplyx on GitHub (Jul 27, 2025).

Originally assigned to: @vhsdream on GitHub.

✅ Have you read and understood the above guidelines?

yes

📜 What is the name of the script you are using?

karakeep

📂 What was the exact command used to execute the script?

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/karakeep.sh)"

⚙️ What settings are you using?

  • Default Settings
  • Advanced Settings

🖥️ Which Linux distribution are you using?

Debian 12

📝 Provide a clear and concise description of the issue.

In my /etc/karakeep/karakeep.env file I set a custom DATA_DIR (e.g. DATA_DIR="/mnt/Hoarder"). This causes the DB not to be migrated on updates, as the script expects the DB to be in the default directory (/opt/karakeep_data)

🔄 Steps to reproduce the issue.

  1. Install Karakeep via the script
  2. Change the DATA_DIR in /etc/karakeep/karakeep.env to a different location and copy the original DB from /opt/karakeep_data to the new location
  3. Run the script to update karakeep to a newer version

Now karakeep will probably not start and log errors due to the missing DB migration.

❌ Paste the full error output (if available).

Karakeep log contains various DB erros (e.g. columns not existing) due to the missing migration.

🖼️ Additional context (optional).

The issue lies in this line, where the DATA_DIR is set to a hardcoded value:

67973ada07/ct/karakeep.sh (L75)

Instead the value from the /etc/karakeep/karakeep.env file should probably be used.

Originally created by @Zuplyx on GitHub (Jul 27, 2025). Originally assigned to: @vhsdream on GitHub. ### ✅ Have you read and understood the above guidelines? yes ### 📜 What is the name of the script you are using? karakeep ### 📂 What was the exact command used to execute the script? bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/karakeep.sh)" ### ⚙️ What settings are you using? - [x] Default Settings - [ ] Advanced Settings ### 🖥️ Which Linux distribution are you using? Debian 12 ### 📝 Provide a clear and concise description of the issue. In my `/etc/karakeep/karakeep.env` file I set a custom `DATA_DIR` (e.g. `DATA_DIR="/mnt/Hoarder"`). This causes the DB not to be migrated on updates, as the script expects the DB to be in the default directory (`/opt/karakeep_data`) ### 🔄 Steps to reproduce the issue. 1. Install Karakeep via the script 2. Change the `DATA_DIR` in `/etc/karakeep/karakeep.env` to a different location and copy the original DB from `/opt/karakeep_data` to the new location 3. Run the script to update karakeep to a newer version Now karakeep will probably not start and log errors due to the missing DB migration. ### ❌ Paste the full error output (if available). Karakeep log contains various DB erros (e.g. columns not existing) due to the missing migration. ### 🖼️ Additional context (optional). The issue lies in this line, where the `DATA_DIR` is set to a hardcoded value: https://github.com/community-scripts/ProxmoxVE/blob/67973ada075bd86bd38ce6d1134a26df86d81735/ct/karakeep.sh#L75 Instead the value from the `/etc/karakeep/karakeep.env` file should probably be used.
OVERLORD added the enhancement label 2026-02-05 00:26:31 +03:00
OVERLORD commented 2026-02-05 00:26:38 +03:00
Author
Owner
Copy Link

@MickLesk commented on GitHub (Jul 27, 2025):

Set an Symlink?

Its the official Version and Approved and confirmed Version by karakeep Maintainer. Basically, it is not a script issue, as any changes are not covered by it. If so, it is a feature request.

@MickLesk commented on GitHub (Jul 27, 2025): Set an Symlink? Its the official Version and Approved and confirmed Version by karakeep Maintainer. Basically, it is not a script issue, as any changes are not covered by it. If so, it is a feature request.
OVERLORD commented 2026-02-05 00:26:43 +03:00
Author
Owner
Copy Link

@Zuplyx commented on GitHub (Jul 27, 2025):

Yes, that's what I ended up doing. But I still think this situation could be handled better by the script. Since changing the DATA_DIR in the configuration is a feature of karakeep, in my opinion the update script should also support this instead of relying on a hardcoded path.

Alternatively if you don't want to change the script, I think it would be great to mention somewhere on the script's page, that changing the DATA_DIR requires additional measures. The current description implied to me that I could just change the configuration and everything would continue working.

@Zuplyx commented on GitHub (Jul 27, 2025): Yes, that's what I ended up doing. But I still think this situation could be handled better by the script. Since changing the `DATA_DIR` in the configuration is a feature of karakeep, in my opinion the update script should also support this instead of relying on a hardcoded path. Alternatively if you don't want to change the script, I think it would be great to mention somewhere on the script's page, that changing the `DATA_DIR` requires additional measures. The current description implied to me that I could just change the configuration and everything would continue working.
OVERLORD commented 2026-02-05 00:26:46 +03:00
Author
Owner
Copy Link

@vhsdream commented on GitHub (Jul 27, 2025):

@Zuplyx thank you for the suggestion. While updating, the script will now use the DATA_DIR from the env file; the mechanics of moving the database files is still an exercise left to the end-user though.

Implemented in #6283

@vhsdream commented on GitHub (Jul 27, 2025): @Zuplyx thank you for the suggestion. While updating, the script will now use the DATA_DIR from the env file; the mechanics of moving the database files is still an exercise left to the end-user though. Implemented in #6283
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Implemented in VED waiting push to Main
breaking change
bug
bug
bugfix
deferred
delete script
dependencies
enhancement
external
feature
github
help wanted
in project pipeline
invalid
investigation
json
maintenance
needs triage
new script
new script
nice to have
not a script issue
not planned
organization
pull-request
Mirrored from GitHub Pull Request
 question
refactor
rename script
security
update script
website
wontdo
🛑 Failure to comply with the guidelines
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/ProxmoxVE#1349
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?