starred/ProxmoxVE

Fork 0

mirror of https://github.com/community-scripts/ProxmoxVE.git synced 2026-04-26 01:36:05 +03:00

[GH-ISSUE #10437] Scanopy configure_daemon.sh does not work due to api-key mismatch #2252

New issue

Closed

opened 2026-02-26 12:51:48 +03:00 by kerem · 6 comments

kerem commented

2026-02-26 12:51:48 +03:00

Owner

Originally created by @durzo on GitHub (Dec 30, 2025).
Original GitHub issue: https://github.com/community-scripts/ProxmoxVE/issues/10437

Originally assigned to: @vhsdream on GitHub.

✅ Have you read and understood the above guidelines?

yes

🔎 Did you run the script with verbose mode enabled?

Yes, verbose mode was enabled and the output is included below

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

scanopy

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

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

⚙️ What settings are you using?

Default Settings
Advanced Settings

🖥️ Which Linux distribution are you using?

Debian 13

📈 Which Proxmox version are you on?

9.1.4

📝 Provide a clear and concise description of the issue.

The included script /root/configure_daemon.sh pulls the API key from the database table api_keys and passes it as the value of --daemon-api-key in the created systemd file for scanopy-daemon

The problem is, the API key stored in the api_keys table is a hash of the key, not the key itself. this results in the daemon registration failing due to an invalid api key, and it getting stuck in a retry/restart loop.

it does not look like the api key is obtainable from the db table, so the script itself may have to be removed or altered to prompt for manual api key insertion

🔄 Steps to reproduce the issue.

create the lxc using the install script
open the webui and create a new account, do nothing else.
inside the lxc, run /root/configure_daemon.sh
journalctl -fu scanopy-daemon shows the registration failure
cat /etc/systemd/system/scanopy-daemon shows the api key hash taken from the DB.
note its length (65 chars). api keys are 33 chars in length.
in the web ui, create a new API key, note the key and its length (33 chars)
select all rows from api_keys table, the api key is 65 chars and not the original key (its a hash)

❌ Paste the full error output (if available).

Dec 30 23:38:33 scanopy scanopy-daemon[18451]: 2025-12-30T23:38:33.177371Z  WARN scanopy::daemon::runtime::service: API key not yet active. This daemon was likely installed before account registration was completed. Waiting for account creation... Retrying in 16 seconds. daemon_id=6c5b6833-9163-405f-aaf4-ad20b796a6af attempt=6

🖼️ Additional context (optional).

No response

Originally created by @durzo on GitHub (Dec 30, 2025). Original GitHub issue: https://github.com/community-scripts/ProxmoxVE/issues/10437 Originally assigned to: @vhsdream on GitHub. ### ✅ Have you read and understood the above guidelines? yes ### 🔎 Did you run the script with verbose mode enabled? Yes, verbose mode was enabled and the output is included below ### 📜 What is the name of the script you are using? scanopy ### 📂 What was the exact command used to execute the script? bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/scanopy.sh)" ### ⚙️ What settings are you using? - [x] Default Settings - [ ] Advanced Settings ### 🖥️ Which Linux distribution are you using? Debian 13 ### 📈 Which Proxmox version are you on? 9.1.4 ### 📝 Provide a clear and concise description of the issue. The included script /root/configure_daemon.sh pulls the API key from the database table api_keys and passes it as the value of `--daemon-api-key` in the created systemd file for scanopy-daemon The problem is, the API key stored in the api_keys table is a hash of the key, not the key itself. this results in the daemon registration failing due to an invalid api key, and it getting stuck in a retry/restart loop. it does not look like the api key is obtainable from the db table, so the script itself may have to be removed or altered to prompt for manual api key insertion ### 🔄 Steps to reproduce the issue. 1. create the lxc using the install script 2. open the webui and create a new account, do nothing else. 3. inside the lxc, run /root/configure_daemon.sh 4. `journalctl -fu scanopy-daemon` shows the registration failure 5. `cat /etc/systemd/system/scanopy-daemon` shows the api key hash taken from the DB. 6. note its length (65 chars). api keys are 33 chars in length. 7. in the web ui, create a new API key, note the key and its length (33 chars) 8. select all rows from api_keys table, the api key is 65 chars and not the original key (its a hash) ### ❌ Paste the full error output (if available). ``` Dec 30 23:38:33 scanopy scanopy-daemon[18451]: 2025-12-30T23:38:33.177371Z WARN scanopy::daemon::runtime::service: API key not yet active. This daemon was likely installed before account registration was completed. Waiting for account creation... Retrying in 16 seconds. daemon_id=6c5b6833-9163-405f-aaf4-ad20b796a6af attempt=6 ``` ### 🖼️ Additional context (optional). _No response_

kerem

2026-02-26 12:51:48 +03:00

closed this issue
added the
bug

external
labels

kerem commented

2026-02-26 12:51:49 +03:00

Author

Owner

@tremor021 commented on GitHub (Dec 31, 2025):

Disregard anything i said.... lol
@vhsdream configure_daemon.sh fetches the hash from DB instead of actual API key. Can we refactor this?

@tremor021 commented on GitHub (Dec 31, 2025): Disregard anything i said.... lol @vhsdream `configure_daemon.sh` fetches the hash from DB instead of actual API key. Can we refactor this?

kerem commented

2026-02-26 12:51:49 +03:00

Author

Owner

@durzo commented on GitHub (Dec 31, 2025):

the actual API key is not stored anywhere in the DB that I can see. I guess it needs to be created by the script either via direct DB insert or a call back to scanopy-server but im not sure thats even possible

@durzo commented on GitHub (Dec 31, 2025): the actual API key is not stored anywhere in the DB that I can see. I guess it needs to be created by the script either via direct DB insert or a call back to scanopy-server but im not sure thats even possible

kerem commented

2026-02-26 12:51:49 +03:00

Author

Owner

@tremor021 commented on GitHub (Dec 31, 2025):

We can surely make configure_daemon.sh ask the user to insert the API key generated in the app, just wanna @vhsdream to give his thoughts, since its his script

I mean, thats what I just did. I hardcoded the network ID and API key in the configure_daemon.sh and ran it like that. It worked fine

@tremor021 commented on GitHub (Dec 31, 2025): We can surely make `configure_daemon.sh` ask the user to insert the API key generated in the app, just wanna @vhsdream to give his thoughts, since its his script I mean, thats what I just did. I hardcoded the network ID and API key in the `configure_daemon.sh` and ran it like that. It worked fine

kerem commented

2026-02-26 12:51:49 +03:00

Author

Owner

@thechickenmoo commented on GitHub (Jan 22, 2026):

I'm not 100% sure why this was closed as not-planned. The script as it is doesn't work.
I used the default install and got stuck. You can't create new daemons in the gui because the config file already exists, but if you run the script designated it puts an incorrect API Key in place, so the daemon can't run either.

I first tried overriding the API Key in the config file and that didn't resolve it (maybe it's obfuscated or encrypted? I didn't dig much on that).

Thanks @tremor021 for mentioning that overriding the API Key in the script worked for you, it resolved my issues as well.

@thechickenmoo commented on GitHub (Jan 22, 2026): I'm not 100% sure why this was closed as not-planned. The script as it is doesn't work. I used the default install and got stuck. You can't create new daemons in the gui because the config file already exists, but if you run the script designated it puts an incorrect API Key in place, so the daemon can't run either. I first tried overriding the API Key in the config file and that didn't resolve it (maybe it's obfuscated or encrypted? I didn't dig much on that). Thanks @tremor021 for mentioning that overriding the API Key in the script worked for you, it resolved my issues as well.

kerem commented

2026-02-26 12:51:49 +03:00

Author

Owner

@tremor021 commented on GitHub (Jan 23, 2026):

Yea, i know, this is a problem that @vhsdream should look at or i will when i get around to it. I'm just swamped atm with script refactors and working on some tooling for the backend. Hope this gets resolved

@tremor021 commented on GitHub (Jan 23, 2026): Yea, i know, this is a problem that @vhsdream should look at or i will when i get around to it. I'm just swamped atm with script refactors and working on some tooling for the backend. Hope this gets resolved

kerem commented

2026-02-26 12:51:49 +03:00

Author

Owner

@vhsdream commented on GitHub (Jan 23, 2026):

I missed this for the longest time since it was opened when I was away. Yeah it's unfortunate (but I guess also good from a security standpoint) that we can't simply grab the API keys in plaintext anymore.

Since this started happening there's also the addition of user API keys for programmatic access to the backend API, which allows for viewing daemon API keys. Might be possible to gin something up, but in the meantime perhaps we'll remove the generated script, since it makes more sense to simply go through the process of creating the daemon via the UI. No reason to do some of it in the UI and the rest in a script.

@vhsdream commented on GitHub (Jan 23, 2026): I missed this for the longest time since it was opened when I was away. Yeah it's unfortunate (but I guess also good from a security standpoint) that we can't simply grab the API keys in plaintext anymore. Since this started happening there's also the addition of user API keys for programmatic access to the backend API, which allows for viewing daemon API keys. Might be possible to gin something up, but in the meantime perhaps we'll remove the generated script, since it makes more sense to simply go through the process of creating the daemon via the UI. No reason to do some of it in the UI and the rest in a script.

kerem referenced this issue

2026-02-26 13:34:11 +03:00

[PR #2252] [CLOSED] [core] Auto-update latest JSON file #3640

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/ProxmoxVE#2252

No description provided.

Rows
Columns