The real issue for PVE 8 users seeing 0% disk usage:
- Users who added nodes BEFORE v4.7 don't have VM.Monitor permission
- The setup script always created tokens with privsep=0, so that wasn't the issue
- Solution: Re-run the setup script or manually add VM.Monitor permission
Updated error messages and documentation to reflect the actual cause
and provide the correct fix for users experiencing this issue.
- Add detailed logging when VM disk monitoring fails due to permissions
- Explain Proxmox 9 limitation: API tokens cannot access guest agent data (PVE bug #1373)
- Explain Proxmox 8 requirements: VM.Monitor permission and privsep=0 for tokens
- Update setup script to show appropriate warnings for each PVE version
- Update FAQ with troubleshooting steps for 0% disk usage on VMs
- Log messages now clearly indicate workarounds for each scenario
The core issue: Proxmox 9 removed VM.Monitor permission and the replacement
permissions don't allow API tokens to access guest agent filesystem info.
This is a Proxmox upstream bug that affects their own web UI as well.
For users experiencing this issue:
- PVE 9: Use root@pam credentials or wait for Proxmox to fix upstream
- PVE 8: Ensure token has VM.Monitor and privsep=0
- All versions: QEMU guest agent must be installed in VMs
- LXC containers run as root and don't have sudo installed
- Updated all documentation to remove sudo references
- Updated frontend UI to show correct install command
- Keep sudo mention only in troubleshooting for edge cases
- Changed from showing just percentage to "X.X GB free of Y.Y GB (Z% used)"
- Much more useful for users to see actual available space
- Applies to both Quick and Advanced installation modes
addresses #348
After extensive testing and research:
CONFIRMED: This is a Proxmox 9 API limitation, not a configuration issue
- Guest agent get-fsinfo works when called as root (qm agent <vmid> get-fsinfo)
- API tokens CANNOT access this data even with VM.GuestAgent.Audit permission
- Proxmox's own web UI also shows 0% for VM disk usage (bug #1373)
Updated:
- Setup script now clearly explains this is a known Proxmox limitation
- Changed log level from Warn to Debug for permission errors (expected on PVE 9)
- Added references to Proxmox bug #1373
Workarounds for users:
1. Use root@pam credentials instead of API tokens for full VM disk monitoring
2. Container (LXC) disk usage works correctly with tokens
3. Wait for Proxmox to fix this upstream
The guest agent returns the data (total-bytes, used-bytes) but Proxmox's
API doesn't allow token access to it. This is not something we can fix
in Pulse - it needs to be addressed in Proxmox itself.
addresses #348
After testing on actual PVE 9.0.5 nodes:
- Confirmed VM.Monitor privilege was removed in PVE 9
- PVEAuditor role includes VM.GuestAgent.Audit permission
- Added Sys.Audit permission (replacement for VM.Monitor)
- Added clear warning about known PVE 9 guest agent limitations
The issue appears to be a Proxmox 9 limitation where even with correct
permissions (VM.GuestAgent.Audit + Sys.Audit), the guest agent API may
not return disk usage data for non-root tokens. This is likely a bug or
intentional security restriction in Proxmox 9 that needs to be addressed
upstream.
Updated setup script to:
1. Properly detect PVE 9 and add appropriate permissions
2. Warn users about the known limitation
3. Suggest workarounds (using root credentials if needed)
addresses #348
- Updated setup script to properly detect and handle Proxmox 9 where VM.Monitor was removed
- For PVE 9+, now creates custom role with Sys.Audit permissions (replaces VM.Monitor)
- Attempts to add VM.Agent or Sys.Modify permissions for better guest agent access
- Added better error logging to identify permission issues with guest agent API
- Warns users about PVE 9 permission requirements if disk usage shows 0%
The setup script now:
1. Properly detects PVE version using pveversion command
2. Creates appropriate roles based on PVE version (VM.Monitor for PVE 8, Sys.Audit for PVE 9)
3. Provides clear instructions if guest agent access still doesn't work
The SecurityHeaders middleware was not being applied to the router,
causing the "Allow iframe embedding" setting to not take effect.
This fix properly applies the middleware with the saved settings,
allowing iframe embedding to work when enabled.
addresses #351
addresses #352
quick mode now:
- shows available network bridges and prompts for selection
- shows available storage pools with usage info and prompts for selection
- properly handles cases where defaults (vmbr0, local-lvm) don't exist
- gives clear error messages when no bridges or storage pools are found
this ensures users always see what's available and can make informed choices
even in quick mode, preventing installation failures due to missing defaults
addresses #352
the installer now:
- detects the actual default network interface (not just vmbr*)
- uses the first available bridge if default isn't a bridge
- prompts user to select a bridge when vmbr0 doesn't exist
- shows helpful messages when no bridges are detected
this fixes issues on systems with non-standard network configurations
where vmbr0 doesn't exist or isn't the default gateway
Initialize RC_VERSION to empty string before assignment to prevent
'unbound variable' errors when running with set -u. This ensures
the RC update option is shown when running a stable version.
The version detection regex now captures the full version string including
pre-release suffixes like -rc.1, -beta.2, etc. This prevents the script
from offering to update to a version that's already installed.
- Fixed safe_read function to properly handle TTY availability
- Added proper error handling for compare_versions return codes
- Script no longer exits silently when selecting menu options
The update and reinstall cases in the menu were missing exit statements,
causing the script to continue running after completion and hit the fresh
install path. This made it appear as if nothing happened when selecting
menu options.
Added exit 0 after print_completion for both update and reinstall cases.
Removed debug output now that the issue is resolved.
- Simplified safe_read function to properly handle TTY input when script is piped
- Added error check if no option is selected
The menu now correctly reads user input when running:
curl -sSL .../install.sh | bash
The script now properly detects update scenarios by checking for:
- Existing binary at /opt/pulse/bin/pulse or /opt/pulse/pulse
- Existing config directory at /etc/pulse
- --version flag being specified
This prevents the annoying port prompt when running updates or installing specific versions.
Addresses #222 - Allow Pulse to be embedded in iframes (e.g., Homepage dashboard)
- Add AllowEmbedding and AllowedEmbedOrigins settings to SystemSettings
- Update security headers to respect embedding configuration
- When disabled: X-Frame-Options: DENY, frame-ancestors 'none'
- When enabled (same-origin): X-Frame-Options: SAMEORIGIN, frame-ancestors 'self'
- When enabled with origins: Adds specified origins to frame-ancestors
- Add UI controls in Settings → System → Network Settings
- Properly handle CSP frame-ancestors directive for cross-origin embedding
Users can now enable iframe embedding and specify allowed origins for embedding Pulse in Homepage or other dashboard applications.
The menu now only shows update options for versions different from
the currently installed version. This prevents confusing situations
where users can 'update' to the version they already have.
- Redirect apt-get update/install stderr to /dev/null to hide GPG warnings
- Suppress systemctl enable output (Created symlink message)
- Suppress systemctl daemon-reload output
- Makes the installation output cleaner and less scary for users
The remove option now:
- Removes symlink at /usr/local/bin/pulse
- Asks before removing config/data in /etc/pulse
- Asks before removing the pulse user account
- Cleans up log files
- Removes all possible service file variations
- Runs systemctl daemon-reload after service removal
The install script was exiting when --version flag was used due to set -e
and compare_versions returning 2 for downgrades. Now properly captures
the return value and also detects the correct service name.
Added two export options in Settings > System:
- Export Full: Complete diagnostic data for private troubleshooting
- Export for GitHub: Sanitized version with redacted sensitive information
The sanitized export:
- Replaces IP addresses with xxx.xxx.xxx.xxx (keeping first octet for context)
- Replaces hostnames with generic names (keeping .lan/.local suffix)
- Redacts API token names and cluster names
- Adds a notice that data has been sanitized
- Filenames clearly indicate 'sanitized' vs 'full'
This allows users to safely share diagnostic data on public GitHub issues
without exposing their network topology or internal naming conventions.
Improved logging to help users diagnose why VM disk usage might not be showing:
- Clearly identify when agent is enabled in config but not running in guest OS
- Detect timeout issues with unresponsive agents
- Log when agent returns no filesystem info
- Show which filesystems are included/excluded from calculations
- Distinguish between no agent, agent not running, and agent working
This will help users understand exactly why their VM disk usage isn't showing
and what steps they need to take to fix it (install qemu-guest-agent, restart
the service, etc).
addresses discussion #344
The agent field in Proxmox can have values other than just 0 or 1 when features are enabled, causing the strict equality check (== 1) to fail. Changed to check for any value > 0 to properly detect when the agent is enabled.
addresses discussion #344
- Says 'Updating to' when installing a newer version
- Says 'Downgrading to' when installing an older version
- Says 'Reinstalling' when installing the same version
- Says 'Installing' when current version is unknown
Added version comparison function to determine the right action word.
The install script was failing with 'unbound variable' error after completing an update because FRONTEND_PORT is only set during fresh installations. Now extracts port from service file or uses default.
The install script was using 'set -e' which caused it to exit when grep didn't find updateChannel in system.json. Added '|| true' to prevent early exit.
Also improved version detection with fallback when GitHub API is rate-limited.
The temporary auth tokens generated by authenticated users are now properly
validated even when Pulse has authentication enabled. This fixes the issue
where fresh installs (which are secured by default) couldn't use the
auto-registration feature.
Replaced the two-step setup code process with a simpler token-in-URL approach:
- Auth token is now embedded directly in the setup URL
- No more prompting users for setup codes
- Same security level with better UX
- Backwards compatible with old setupCode field
The new flow generates a command like:
curl -sSL "http://pulse/api/setup-script?...&auth_token=TOKEN" | bash
This makes it much easier for users, especially in Proxmox shell where
interactive prompts can be problematic.
- The generated command now includes PULSE_SETUP_CODE environment variable
- Users can simply copy-paste the command in Proxmox shell without needing to type the code
- Makes the setup process more streamlined for the primary use case
addresses #350 - removes the pre-v4 installation check that was causing false positives when .env files were accidentally placed in /opt/pulse. V3 is no longer supported.
- Add bulk acknowledge and clear operations for alerts
- Support selecting multiple alerts with checkboxes
- Add select all functionality for bulk operations
- Improve Proxmox permission setup to handle both PVE 8 and 9+
- Use PVEAuditor role which includes VM.GuestAgent.Audit for PVE 9+
- Add fallback VM.Monitor role for PVE 8 and below
- Bump version to 4.7.3
- Fixed parsing of pveversion output (uses colon separator not slash)
- Now correctly extracts version number from 'pve-manager: X.Y.Z' format
- addresses #348
- Detect Proxmox version in setup script
- Use VM.GuestAgent.Audit for PVE 9+ instead of VM.Monitor
- Update UI instructions to handle both PVE 8 and 9
- addresses #348
- Gotify was missing from the service type dropdown
- Users were forced to use generic webhook which doesn't include required 'message' field
- Now users can select Gotify service type which applies the correct template
- Addresses #342 - actually fixes Gotify webhook notifications
- Webhook test was showing success even when receiving 400/500 errors
- Now correctly reports HTTP status errors to the UI
- Added debug logging for Gotify webhooks to help troubleshooting
- Addresses #342 where Gotify webhooks appeared to work but didn't
- Setup script no longer requires authentication (uses setup codes instead)
- Fixed discovery service not starting when toggled via settings
- Addresses #347 and discussion #344
Pulse Monitor