SVI/ProxmoxVE
1
0
Fork 0
mirror of https://github.com/community-scripts/ProxmoxVE.git synced 2026-03-31 06:34:17 -04:00
Code Issues 2.6k Packages Projects Releases 10 Wiki Activity

Zipline installer and updater issues - Dataloss #957

New Issue
Closed
opened 2025-11-20 04:57:13 -05:00 by saavagebueno · 0 comments
saavagebueno commented 2025-11-20 04:57:13 -05:00
Owner
Copy Link

Originally created by @biosniper on GitHub (Apr 21, 2025).

✅ Have you read and understood the above guidelines?

yes

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

Zipline

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

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

⚙️ What settings are you using?

  • Default Settings
  • Advanced Settings

🖥️ Which Linux distribution are you using?

No response

📝 Provide a clear and concise description of the issue.

Zip[line v4 - The install script for Zipline puts the user Upload data dir inside of /opt/zipline as the default setting (creates /opt/zipline) as the .env does not contain suitable vars to put the data outside of this dir

Example From docs https://zipline.diced.sh/docs/config/datasource :

DATASOURCE_TYPE=local
DATASOURCE_LOCAL_DIRECTORY=./uploads

CT script on line 43 contains the following function: rm -R /opt/zipline
The recursive remove of this dir removes /opt/zipline/upload and thus all user uploaded data
Suggestion to move data to /opt/zline-uploads as default config or other suitable location to prevent loss when erasing install for update. Alternative would be to pull from git for install rather than the zip as per official docs https://zipline.diced.sh/docs/get-started/source

Additionally if using an existing Zipline v3 install no sanity / safety check is performed when running the upgrade script and v4 being the upgrade version.
This results in Zipline installation being destroyed incl. uploads dir, and application becoming non-runnable due to database schema changes.
Suggest adding a sanity check if version is 3 to error back to CLI and stop user upgrading and suggeting they read the documentation for upgrade or install a new CT and restore data export from v3 install.

Additional Additional
Dir removal takes place BEFORE downloading update files. If internet connection fails mid update (this happened to me), install becomes non-usable as dir is removed. Running upgrade script again doesnt fix the install as it no longer exists during check and throws "not installed" error.
Suggestion to pull files BEFORE removing data from disk to prevent such failure. All install tasks as far as possible should be run before destructive actions.

🔄 Steps to reproduce the issue.

Run Zipline
Upload data
Check data dir
Run upgrade script to new version (modify version txt to a lower version ID to force update for testing)
Check user data again in web app as not existing

❌ Paste the full error output (if available).

none

🖼️ Additional context (optional).

No response

Originally created by @biosniper on GitHub (Apr 21, 2025). ### ✅ Have you read and understood the above guidelines? yes ### 📜 What is the name of the script you are using? Zipline ### 📂 What was the exact command used to execute the script? bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/zipline.sh)" ### ⚙️ What settings are you using? - [x] Default Settings - [ ] Advanced Settings ### 🖥️ Which Linux distribution are you using? _No response_ ### 📝 Provide a clear and concise description of the issue. Zip[line v4 - The install script for Zipline puts the user Upload data dir inside of `/opt/zipline` as the default setting (creates /opt/zipline) as the .env does not contain suitable vars to put the data outside of this dir Example From docs https://zipline.diced.sh/docs/config/datasource : ``` DATASOURCE_TYPE=local DATASOURCE_LOCAL_DIRECTORY=./uploads ``` CT script on line 43 contains the following function: `rm -R /opt/zipline` The recursive remove of this dir removes `/opt/zipline/upload` and thus all user uploaded data Suggestion to move data to `/opt/zline-uploads` as default config or other suitable location to prevent loss when erasing install for update. Alternative would be to pull from git for install rather than the zip as per official docs https://zipline.diced.sh/docs/get-started/source **Additionally if using an existing Zipline v3 install** no sanity / safety check is performed when running the upgrade script and v4 being the upgrade version. This results in Zipline installation being destroyed incl. uploads dir, and application becoming non-runnable due to database schema changes. Suggest adding a sanity check if version is 3 to error back to CLI and stop user upgrading and suggeting they read the documentation for upgrade or install a new CT and restore data export from v3 install. **Additional Additional** Dir removal takes place BEFORE downloading update files. If internet connection fails mid update (this happened to me), install becomes non-usable as dir is removed. Running upgrade script again doesnt fix the install as it no longer exists during check and throws "not installed" error. Suggestion to pull files BEFORE removing data from disk to prevent such failure. All install tasks as far as possible should be run before destructive actions. ### 🔄 Steps to reproduce the issue. Run Zipline Upload data Check data dir Run upgrade script to new version (modify version txt to a lower version ID to force update for testing) Check user data again in web app as not existing ### ❌ Paste the full error output (if available). none ### 🖼️ Additional context (optional). _No response_
saavagebueno added the bug label 2025-11-20 04:57:13 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
🛑 Failure to comply with the guidelines
breaking change
bug
bug
bugfix
deferred
delete script
dependencies
enhancement
external
feature
github
help wanted
Implemented in VED waiting push to Main
in project pipeline
invalid
investigation
json
maintenance
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
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/ProxmoxVE#957
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?