[GH-ISSUE #484] 0.5.6: Auto-Detect -> 0 Running LXC Containers? #140

Open
opened 2026-02-26 12:40:17 +03:00 by kerem · 12 comments
Owner

Originally created by @white-rabbit07 on GitHub (Jan 30, 2026).
Original GitHub issue: https://github.com/community-scripts/ProxmoxVE-Local/issues/484

Hi.
My old ProxmoxVE-Local-installation (0.5.3) didn't work anymore.
So I removed it and installed a new LXC-Container; this time: 0.5.6.

Then I connected the script to the PVE-Host ("Test connection" was successful) and afterwards I tried to
"Auto-Detect Containers & VMs".

The result is always:
0 Running LXC
0 Running VMs
... but that's not true. I have several running LXC/VMs (also tagged with "community script").
What's wrong there?
Thanks!

Originally created by @white-rabbit07 on GitHub (Jan 30, 2026). Original GitHub issue: https://github.com/community-scripts/ProxmoxVE-Local/issues/484 Hi. My old ProxmoxVE-Local-installation (0.5.3) didn't work anymore. So I removed it and installed a new LXC-Container; this time: 0.5.6. Then I connected the script to the PVE-Host ("Test connection" was successful) and afterwards I tried to "Auto-Detect Containers & VMs". The result is always: 0 Running LXC 0 Running VMs ... but that's not true. I have several running LXC/VMs (also tagged with "community script"). What's wrong there? Thanks!
Author
Owner

@novafire99 commented on GitHub (Jan 31, 2026):

First time installing it and seeing the same. PVE 9.1.4 ZFS and 0.5.6 of the script, cannot see any of the previously installed scripts even though they are tagged right.

<!-- gh-comment-id:3829535950 --> @novafire99 commented on GitHub (Jan 31, 2026): First time installing it and seeing the same. PVE 9.1.4 ZFS and 0.5.6 of the script, cannot see any of the previously installed scripts even though they are tagged right.
Author
Owner

@michelroegl-brunner commented on GitHub (Feb 1, 2026):

Welp, might have broken something, i did a few refactors last week. I take a look tomorrow and publish a patch when it is fixed.

<!-- gh-comment-id:3830728797 --> @michelroegl-brunner commented on GitHub (Feb 1, 2026): Welp, might have broken something, i did a few refactors last week. I take a look tomorrow and publish a patch when it is fixed.
Author
Owner

@jeffbyrnes commented on GitHub (Feb 13, 2026):

Totally new install of this, seeing this same behavior despite having multiple community-script LXC containers running on my ProxMox setup.

Look forward to a fix, this seems handy!

<!-- gh-comment-id:3898484304 --> @jeffbyrnes commented on GitHub (Feb 13, 2026): Totally new install of this, seeing this same behavior despite having multiple `community-script` LXC containers running on my ProxMox setup. Look forward to a fix, this seems handy!
Author
Owner

@dccrain commented on GitHub (Feb 16, 2026):

same here

<!-- gh-comment-id:3906027883 --> @dccrain commented on GitHub (Feb 16, 2026): same here
Author
Owner

@Gurgi66 commented on GitHub (Feb 19, 2026):

I have the same problem ...

<!-- gh-comment-id:3926105802 --> @Gurgi66 commented on GitHub (Feb 19, 2026): I have the same problem ...
Author
Owner

@wokieman commented on GitHub (Feb 21, 2026):

I have the same problem.Is there any fix?

<!-- gh-comment-id:3938685240 --> @wokieman commented on GitHub (Feb 21, 2026): I have the same problem.Is there any fix?
Author
Owner

@iaing80 commented on GitHub (Feb 21, 2026):

Same issue, old version no longer worked. Blatted and redployed to the latest but scans are not working on any of the 4 hosts.

<!-- gh-comment-id:3939618004 --> @iaing80 commented on GitHub (Feb 21, 2026): Same issue, old version no longer worked. Blatted and redployed to the latest but scans are not working on any of the 4 hosts.
Author
Owner

@donut-z commented on GitHub (Feb 22, 2026):

Seems to be the same for me. Just did a fresh install, SSH connection appears to work, .conf files contain "community-script" tag but are not detected.

<!-- gh-comment-id:3941675645 --> @donut-z commented on GitHub (Feb 22, 2026): Seems to be the same for me. Just did a fresh install, SSH connection appears to work, <containerid>.conf files contain "community-script" tag but are not detected.
Author
Owner

@writzthecat commented on GitHub (Feb 24, 2026):

same here...

<!-- gh-comment-id:3954518885 --> @writzthecat commented on GitHub (Feb 24, 2026): same here...
Author
Owner

@trynity commented on GitHub (Feb 25, 2026):

I will actually have to thank Claude here for figuring out the exact issue, since I had the following error in the logs to at least go off of:

Feb 25 13:10:16 pve-scripts-local npm[198]: DB object in getLXCConfig: []
Feb 25 13:10:16 pve-scripts-local npm[198]: getLXCConfigByScriptId exists: function
Feb 25 13:10:16 pve-scripts-local npm[198]: Error in getLXCConfig: Error: Command failed with exit code 1
Feb 25 13:10:16 pve-scripts-local npm[198]:     at <unknown> (.next/server/app/api/trpc/[trpc]/route.js:8:62040)
Feb 25 13:10:16 pve-scripts-local npm[198]:     at <unknown> (.next/server/chunks/954.js:1:4315)
Claude Output, Potentially Half Wrong

Why This Happens

The config path uses server.name as the Proxmox node name:

const nodeName = (server as Server).name;
const configPath = `/etc/pve/nodes/${nodeName}/lxc/${script.container_id}.conf`;

This fails when:

  1. server.name doesn't match the actual Proxmox node name — e.g., you named your server "My Server" in the app but the Proxmox node is named pve or proxmox.
  2. The container is on a different node than what server.name resolves to.
  3. The LXC config file simply doesn't exist yet (container was deleted, or config path is wrong).

Note also that the 2>/dev/null suppresses stderr, but the command still exits with code 1 when the file is missing, which then gets rejected as an error.

What I noticed is I had set my node name in PVE Scripts as nodename.domain.com, whereas it's just named nodename in ProxMox. This resulted in it trying to find the node-specific files, due to this change: github.com/community-scripts/ProxmoxVE-Local@6d2df9929c and failing because nodename inconsistency,.

So ensure your node name in the PVE Script settings matches what node name ProxMox is set to, and now it automagically imported everything.

I am not a TypeScript or JavaScript developer in the slightest, but this at least seems to fix the issue. Likely it should error out sooner, such as noting the entire nodename directory doesn't exist, or falling back to non-node specific paths like in previous behavior.

<!-- gh-comment-id:3962176924 --> @trynity commented on GitHub (Feb 25, 2026): I will actually have to thank Claude here for figuring out the exact issue, since I had the following error in the logs to at least go off of: ``` Feb 25 13:10:16 pve-scripts-local npm[198]: DB object in getLXCConfig: [] Feb 25 13:10:16 pve-scripts-local npm[198]: getLXCConfigByScriptId exists: function Feb 25 13:10:16 pve-scripts-local npm[198]: Error in getLXCConfig: Error: Command failed with exit code 1 Feb 25 13:10:16 pve-scripts-local npm[198]: at <unknown> (.next/server/app/api/trpc/[trpc]/route.js:8:62040) Feb 25 13:10:16 pve-scripts-local npm[198]: at <unknown> (.next/server/chunks/954.js:1:4315) ``` <details> <summary>Claude Output, Potentially Half Wrong</summary> # Why This Happens The config path uses server.name as the Proxmox node name: ```TypeScript const nodeName = (server as Server).name; const configPath = `/etc/pve/nodes/${nodeName}/lxc/${script.container_id}.conf`; ``` This fails when: 1. `server.name` doesn't match the actual Proxmox node name — e.g., you named your server "My Server" in the app but the Proxmox node is named `pve` or `proxmox`. 2. The container is on a different node than what server.name resolves to. 3. The LXC config file simply doesn't exist yet (container was deleted, or config path is wrong). Note also that the 2>/dev/null suppresses stderr, but the command still exits with code 1 when the file is missing, which then gets rejected as an error. </details> What I noticed is I had set my node name in PVE Scripts as nodename.domain.com, whereas it's just named nodename in ProxMox. This resulted in it trying to find the node-specific files, due to this change: https://github.com/community-scripts/ProxmoxVE-Local/commit/6d2df9929c21bd3ce7dc4bec9ec2dd3c37994770 and failing because nodename inconsistency,. So ensure your node name in the PVE Script settings matches what node name ProxMox is set to, and now it automagically imported everything. I am not a TypeScript or JavaScript developer in the slightest, but this at least seems to fix the issue. Likely it should error out sooner, such as noting the entire nodename directory doesn't exist, or falling back to non-node specific paths like in previous behavior.
Author
Owner

@wokieman commented on GitHub (Feb 25, 2026):

works like a charm.you are a life saver thank you

<!-- gh-comment-id:3962331930 --> @wokieman commented on GitHub (Feb 25, 2026): works like a charm.you are a life saver thank you
Author
Owner

@novafire99 commented on GitHub (Feb 25, 2026):

This partually fixed the problem, would be good if the script detected the problem, or instead have it automatically set it when adding the server.

It only detected the low numbered ID, which just happens to be the the ProxmoxVE-local in my case (101). All the reset of my id's are much larger eg: 19216802, and not exactly sequential, I can manually add them, but it won't auto detect them.

<!-- gh-comment-id:3962452154 --> @novafire99 commented on GitHub (Feb 25, 2026): This partually fixed the problem, would be good if the script detected the problem, or instead have it automatically set it when adding the server. It only detected the low numbered ID, which just happens to be the the ProxmoxVE-local in my case (101). All the reset of my id's are much larger eg: 19216802, and not exactly sequential, I can manually add them, but it won't auto detect them.
Sign in to join this conversation.
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-Local#140
No description provided.