GUI troubleshooting: Difference between revisions

Revision as of 16:56, 5 January 2026

This page provides troubleshooting tips and debugging techniques for the VoIPmonitor web GUI.

GUI Debug Mode

The GUI debug mode allows you to see SQL queries and other debugging information directly in your browser's Developer Console.

Enabling Debug Mode

To enable debug mode in the VoIPmonitor web GUI, add the parameter ?debug=31415 to the end of any GUI URL. For example:

http://your-server/voipmon/admin.php?debug=31415

This enables the following features:

SQL queries executed by the GUI are logged to the browser's Developer Console
Additional debugging information is displayed for dashboard panels and charts
Performance timing and query execution details become visible

Finding SQL Queries for Dashboard Panels

To see the exact SQL query executed by a dashboard panel:

Add ?debug=31415 to your GUI URL and navigate to the dashboard
Open your browser's Developer Tools (press F12 or Ctrl+Shift+I)
Switch to the Console tab
Interact with the dashboard (e.g., refresh, change time range, or hover over panels)
The SQL queries will be printed to the console log

The queries appear in the console in the order the panels are rendered. If you need to isolate a specific panel, hover over it or interact with its filters after loading the page - this often triggers a re-query which will appear as a new entry in the console.

Disabling Debug Mode

Simply remove the ?debug=31415 parameter from the URL, or navigate to any GUI page without it. Debug mode is not persistent and must be re-enabled each time by adding the URL parameter.

GUI Upgrade Issues

The following are common issues that may occur during GUI upgrades and their solutions.

"Invalid compressed data in update file" Error

If the GUI update fails with the error "Invalid compressed data in update file", this is often caused by incorrect ownership of the web root directory. The web server user needs write permission to extract and install the update files.

Symptoms

GUI update aborts with error: "Invalid compressed data in update file"
Manual reinstallation via tar.gz extraction works fine
The update process cannot write files to the web root directory

Root Cause

The web server process (Apache, httpd, nginx, etc.) runs under a specific user account (typically apache, www-data, or nginx). If the web root directory (typically /var/www/html or /var/www/voipmonitor) is owned by a different user, the update process will fail when attempting to extract and install the update files. The error message is misleading and appears to indicate a corrupted download, but the actual issue is a write permission problem.

Solution: Fix Web Root Directory Ownership

Verify and fix the ownership of the web root directory:

# Check current ownership of the web root
ls -ld /var/www/html
# or
ls -ld /var/www/voipmonitor

# Determine your web server user:
# Debian/Ubuntu: www-data
# CentOS/RHEL: apache
# Nginx: nginx

# Fix ownership - replace with your actual web server user and path
# For Debian/Ubuntu
sudo chown -R www-data:www-data /var/www/html

# For CentOS/RHEL/AlmaLinux
sudo chown -R apache:apache /var/www/html

# For Nginx
sudo chown -R nginx:nginx /var/www/html

After fixing the ownership, retry the GUI update process.

Verifying the Fix

Ensure the web server user can write to the web root:

# For Debian/Ubuntu
sudo -u www-data touch /var/www/html/test_write
sudo rm /var/www/html/test_write

# For CentOS/RHEL
sudo -u apache touch /var/www/html/test_write
sudo rm /var/www/html/test_write

If the test file can be created and deleted, ownership is correct.

Web Portal Inaccessible After Upgrade

If the web portal becomes inaccessible immediately after attempting an upgrade, the web server service may need to be restarted to load the new GUI files correctly. This is often the quickest fix after completing an upgrade.

Solution: Restart the Web Server

# For CentOS/RHEL/AlmaLinux with httpd
sudo systemctl restart httpd

# For Debian/Ubuntu with Apache
sudo systemctl restart apache2

# For nginx with PHP-FPM
sudo systemctl restart php-fpm

After restarting the web server, try accessing the web portal again. If the portal is now accessible, the upgrade was successful and no further action is needed. If the issue persists, proceed with the troubleshooting steps below or consider performing a full GUI reinstallation.

VM Binary (binary missing) Error

If you encounter an error message indicating "VM Binary (binary missing)" during or after a GUI upgrade, this indicates that the GUI application files were not completely updated. Perform a forced CLI upgrade to resolve this issue:

# Log in to the GUI host as root
# Navigate to the GUI installation directory (default is /var/www/html)
cd /var/www/html

# Execute the forced upgrade command
php php/run.php upgrade -f

The -f flag forces a complete upgrade, which updates any missing or corrupt GUI binaries.

Blank Screen with JavaScript ReferenceError After Update

If you can log in to the GUI after an update but are presented with a blank screen, and the browser's JavaScript console shows an error like:

ReferenceError: _AuditActivity_download_wav is not defined

This is typically caused by a conflicting PEAR file that was not removed during the upgrade. The fix is simple:

# Remove the conflicting old PEAR constants file
rm /usr/share/pear/constants.php

# Refresh your browser (Ctrl+Shift+R) to reload the GUI

After removing this file and refreshing the browser, the GUI should load correctly. This issue occurs because the old constants.php file from the system's PEAR installation conflicts with VoIPmonitor's internal JavaScript definitions.

apilicensecheck.php Fatal Error

When calling the Check License API endpoint (php/apilicensecheck.php), you may encounter the following PHP fatal error:

Call to undefined function findExecutableFile()

This is a known bug in certain GUI versions. The solution is to replace the file with a patched version.

Solution: Replace apilicensecheck.php with Patched File

To resolve this issue, obtain the patched apilicensecheck.php file from VoIPmonitor support and perform the following steps:

# 1. Navigate to your GUI installation directory (default is /var/www/html)
cd /var/www/html

# 2. Back up the original file
sudo cp php/apilicensecheck.php php/apilicensecheck.php.backup

# 3. Replace with the patched file from support
# (Copy the patched file to this location, preserving permissions)
sudo cp /path/to/patched/apilicensecheck.php php/apilicensecheck.php

# 4. Ensure correct ownership and permissions
sudo chown www-data:www-data php/apilicensecheck.php
sudo chmod 644 php/apilicensecheck.php

# 5. Verify the fix by testing the API endpoint
curl "http://your-server/php/apilicensecheck.php?task=licenseCheck"

You should receive a JSON response with the license status instead of a PHP error. Example successful responses:

{"status":0,"message":"License OK."}

or

{"status":1,"message":"license file key.php expired. Current date: 2024-01-15 Expiration date: 2024-01-10"}

Note: The patched file must be obtained from VoIPmonitor support. This is not a self-service fix.

MySQL/MariaDB Database Corruption

If the Web GUI fails to start and logs show MySQL/MariaDB database errors (such as corrupted tables, missing files, or startup failures), this indicates database corruption. This can occur after manual file deletion, disk failures, or improper MySQL shutdown procedures.

Symptoms

Web GUI displays database connection errors or shows a blank page
MySQL/MariaDB service fails to start or immediately crashes
Error messages in MySQL logs indicating corrupted tables or missing database files
CDR queries return empty results or throw SQL errors

Diagnosis

First, check the MySQL/MariaDB service status:

# Check if MySQL/MariaDB is running
systemctl status mysql
# or
systemctl status mariadb

# View MySQL error logs for corruption indicators
tail -100 /var/log/mysql/error.log
# or
tail -100 /var/log/mariadb/mariadb.log

Look for error messages such as:

Table is marked as crashed
InnoDB: Database page corruption
Incorrect key file
Can't open file

Solution: Restore from PCAP Files (Recommended)

If the database is corrupted, a complete restore is necessary. The recommended approach is to restore CDR data from the pcap files stored in the spool directory into a new, clean database. This preserves your call recordings and metadata while fixing the corruption issue.

Warning: This procedure requires stopping the VoIPmonitor services and may take significant time depending on the amount of data to restore.

The following diagram illustrates the restoration workflow:

Step 1: Stop VoIPmonitor Services

Stop all VoIPmonitor services to prevent further database corruption:

# Stop the sniffer service
systemctl stop voipmonitor

# Stop sniffer manager (if running)
systemctl stop voipmonitor-manager

# Stop any other VoIPmonitor services
systemctl stop voipmonitor-gui

Step 2: Backup the Corrupted Database

Although corrupted, create a backup of the existing database for troubleshooting purposes:

# Stop MySQL/MariaDB service
systemctl stop mysql

# Create a backup of the MySQL data directory
sudo cp -a /var/lib/mysql /var/lib/mysql-backup-corrupted

Step 3: Remove the Corrupted Database

Move or remove the corrupted database files to prepare for a fresh database:

# Remove the corrupted VoIPmonitor database directory
sudo rm -rf /var/lib/mysql/voipmonitor

# Alternatively, move it instead of deleting:
sudo mv /var/lib/mysql/voipmonitor /var/lib/mysql/voipmonitor.corrupted

Step 4: Start MySQL/MariaDB Service

Restart the MySQL/MariaDB service:

# Start MySQL/MariaDB
systemctl start mysql

# Verify the service is running
systemctl status mysql

Step 5: Create a Fresh VoIPmonitor Database

Create a new empty database for VoIPmonitor:

# Log in to MySQL as root
mysql -u root -p

Run the following SQL commands:

CREATE DATABASE voipmonitor;
CREATE USER 'voipmonitor'@'localhost' IDENTIFIED BY 'your_password_here';
GRANT ALL PRIVILEGES ON voipmonitor.* TO 'voipmonitor'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Replace your_password_here with a strong password.

Step 6: Restore CDRs from PCAP Files

Instruct the sniffer to reprocess all PCAP files from the spool directory and populate the new database:

# 1. Verify your spool directory path
# Check voipmonitor.conf for the spooldir setting (default: /var/spool/voipmonitor)
grep "^spooldir" /etc/voipmonitor.conf

# 2. Clear the sniffer's manager socket for the restore process
# This ensures clean communication with the sniffer
rm -f /tmp/vmsck

# 3. Start the sniffer in restore mode
# The sniffer will read all PCAP files from the spool directory
# and regenerate CDR records in the new database
voipmonitor --config-file /etc/voipmonitor.conf --readpcapdir /var/spool/voipmonitor

Note: The --readpcapdir parameter instructs the sniffer to process all PCAP files in the specified directory. This may take considerable time depending on the amount of historical data.

Step 7: Monitor the Restore Process

Monitor the restore progress:

# Monitor sniffer output for progress
journalctl -u voipmonitor -f

# Alternatively, check the database for new CDR records
mysql -u root -p voipmonitor -e "SELECT COUNT(*) FROM cdr;"

Step 8: Restart Normal Service

Once the restore is complete, restart the sniffer in normal operation mode:

# Stop the restore process (Ctrl+C if running manually)
# Then start the normal sniffer service
systemctl start voipmonitor

# Verify the sniffer is running and capturing
systemctl status voipmonitor

# Test Web GUI access
# Navigate to http://your-server/ in your browser

Prevention: Database Backup Strategies

To avoid future data loss due to database corruption:

Automatic Filesystem Backup

Configure regular backups of the MySQL data directory:

# Example: Daily backup using cron
0 2 * * * /usr/bin/rsync -av --delete /var/lib/mysql/ /backup/mysql-$(date +\%Y\%m\%d)/

MySQL Replication

Set up MySQL master-slave replication for redundancy:

See the Mysql_master-slave_replication_hints guide for detailed instructions
This provides a real-time backup database that can be promoted if corruption occurs

VoIPmonitor Database Replication

Use VoIPmonitor's built-in database backup mode (Redundant_database):

This replicates CDR data to a secondary database server
No traditional MySQL replication required
Useful for GUI migrations and disaster recovery

RRD Graph Errors After Hardware Upgrades

After a hardware upgrade or system migration, RRD (Round Robin Database) graphs in the VoIPmonitor GUI may display errors indicating that Data Sources (DS) are missing from RRD files. This occurs because RRD files are created with a specific hardware-dependent schema that may become incompatible after system changes.

Symptoms

RRD graphs in the Web GUI show display errors instead of rendering data
Error message: ERROR: No DS called '...' in '/var/spool/voipmonitor/rrd/..."'
Example: ERROR: No DS called 'SQLq-SM' in '/var/spool/voipmonitor/rrd/3db-SQL.rrd'
The error appears after hardware upgrades, CPU changes, or system migrations
Multiple RRD files may be affected, affecting various graph types

RRD File Location

RRD files are stored in the RRD directory within the VoIPmonitor spool directory:

/var/spool/voipmonitor/rrd/

Root Cause

RRD (Round Robin Database) files contain time-series data with a schema defined at creation time. Some data sources in RRD files are hardware-specific (e.g., CPU metrics tied to specific CPU identifiers). When hardware changes, the schema information stored in the RRD files may no longer match the current system configuration, resulting in missing Data Source (DS) errors.

Solution: Delete Corrupted RRD Files

The VoIPmonitor service will automatically recreate RRD files with the correct schema if they are missing. This is a safe operation because:

New RRD files will be created with the current hardware's correct schema
Historical RRD data is typically short-term (graph display purposes only)
CDR data and call recordings are stored separately and are not affected

Step 1: Stop the VoIPmonitor Service

Stop the voipmonitor service to prevent file access conflicts:

systemctl stop voipmonitor

Step 2: Remove Corrupted RRD Files

Delete the affected RRD files from the RRD directory. You can remove individual problematic files or the entire RRD directory:

# Option 1: Remove specific corrupted RRD file (recommended)
rm /var/spool/voipmonitor/rrd/3db-SQL.rrd

# Option 2: Remove all RRD files if multiple errors exist
rm /var/spool/voipmonitor/rrd/*

Replace 3db-SQL.rrd with the actual filename from the error message.

Step 3: Start the VoIPmonitor Service

Start the voipmonitor service to recreate the RRD files:

systemctl start voipmonitor

The service will automatically detect the missing RRD files and recreate them with the correct schema based on the current hardware configuration. New graph data will begin accumulating immediately.

Step 4: Verify RRD Graphs

Check the Web GUI to verify that RRD graphs are now displaying correctly:

Navigate to the VoIPmonitor Web GUI
Access dashboard or reporting pages with RRD graphs
Verify that graphs render without errors
Note: Historical data in the affected RRD files will be lost, but new data will start appearing

Rerunning with Different Hardware

If you need to preserve RRD data when moving to different hardware (for example, testing on a different machine), consider these options:

Don't copy RRD files - Let the new system create fresh RRD files with appropriate schemas
Use rrdtool dump/restore - For advanced users, you can modify RRD file contents using rrdtool export/import tools
Accept data loss - RRD data is typically short-term monitoring data, not critical call records

Related Information

RRD files are separate from CDR data (cdr table in MySQL) and PCAP recordings
The VoIPmonitor spooldir location is configurable in /etc/voipmonitor.conf
RRD files are automatically created by the sniffer service when needed

Incorrect Ownership / Permission Errors

If the GUI reports an "incorrect ownership" error even after verifying that the web server user (e.g., apache or www-data) has write permissions to the web root directory, the actual error may be hidden. The web server user needs **execute permissions** on all binary files in the `./bin` directory of the GUI installation.

Symptoms

GUI displays "incorrect ownership" or permission errors
Error persists even after fixing ownership/permissions on the web root directory
Binary files in the bin directory cannot be executed by the web server

Root Cause

The GUI requires the web server user to have execute permissions on all binary files in the `bin` directory (e.g., `sox-x86_64`, `ffmpeg`, etc.). These binaries are used by the GUI for audio processing, call playback, and other features. If the binaries lack execute permissions, the GUI cannot run them.

Solution: Set Execute Permissions on Binaries

Check and fix permissions on all files in the `./bin` directory:

# Navigate to the GUI installation directory (default is /var/www/html)
cd /var/www/html

# Check the bin directory
ls -la bin/

# Set execute permissions on all files in the bin directory
chmod +x bin/*

# For specific binaries, you can set execute permissions individually
chmod +x bin/sox-x86_64
chmod +x bin/ffmpeg

Verifying the Fix

Test that the binaries can be executed by the web server user:

# For Debian/Ubuntu (www-data)
su - www-data -s /bin/bash -c "/var/www/html/bin/sox-x86_64 --version"
# or
su - www-data -s /bin/bash -c "ls -x /var/www/html/bin/"

# For CentOS/RHEL (apache)
su - apache -s /bin/bash -c "/var/www/html/bin/sox-x86_64 --version"
# or
su - apache -s /bin/bash -c "ls -x /var/www/html/bin/"

If the binaries can now be executed, the GUI should work correctly.

Troubleshooting Symlinks

Sometimes the `bin` directory contains symlinks to other locations. Check both the symlink and its target:

# Check if files are symlinks and their targets
ls -lah bin/

# If a symlink cannot be accessed, check permissions on the target
# For example, if bin/sox-x86_64 is a symlink:
ls -l bin/sox-x86_64
ls -l /path/to/real/location/sox-x86_64

# Fix permissions on the target if needed
chmod +x /path/to/real/location/sox-x86_64

Reproducing the Error

To verify that missing execute permissions cause this error, you can temporarily remove execute permissions:

# Remove execute permissions (reproduces the error)
chmod -x bin/sox-x86_64

# Test the GUI - should show "incorrect ownership" error

# Restore execute permissions
chmod +x bin/sox-x86_64

Common Binaries in bin/ Directory

Typical binaries that require execute permissions include:

`sox-x86_64` - Audio conversion tool
`ffmpeg` - Video/audio processing
`soxr` - Audio resampling library
Other utility binaries used by the GUI

IonCube Loader Issues

The VoIPmonitor GUI is protected with IonCube, which requires proper PHP configuration. Common issues include permission errors on temporary directories and security module interference.

Unable to create lock file / temp directory not writable

If you see errors like "Unable to create lock file" or "System temp directory check fails... not writable" from IonCube Loader, follow these troubleshooting steps:

Step 1: Update the system and restart

First, ensure your system packages are up to date:

# Debian/Ubuntu
sudo apt update && sudo apt upgrade -y

# RHEL/CentOS/AlmaLinux
sudo yum update -y
# or
sudo dnf update -y

# Then restart the server
sudo reboot

Step 2: Check SELinux or AppArmor

Security modules like SELinux (default on RHEL/CentOS/Red Hat systems) or AppArmor (default on Ubuntu/Debian) can block IonCube from accessing temporary directories.

Check if SELinux is enabled:

# Check current status
getenforce

# Common values: Enforcing (active), Permissive (logging only), Disabled

# To temporarily disable SELinux for testing:
sudo setenforce 0

If disabling SELinux resolves the issue, you can permanently configure it:

# Edit the SELinux configuration file
sudo nano /etc/selinux/config

# Change SELINUX= to either:
# SELINUX=permissive
# or
# SELINUX=disabled

# Then reboot the server
sudo reboot

Check if AppArmor is enabled:

# Check AppArmor status
sudo aa-status

# If AppArmor is running, temporarily disable individual profiles:
sudo aa-disable /etc/apparmor.d/*php*

# Or disable it entirely for testing:
sudo systemctl stop apparmor
sudo systemctl disable apparmor

Step 3: Check systemd PrivateTmp

Some systemd service configurations use PrivateTmp=true, which creates a private temporary directory for each service. This can cause issues if the private tmp directory has restrictive permissions.

Check if your web server is using PrivateTmp:

# For Apache
systemctl show httpd | grep PrivateTmp
# or
systemctl show apache2 | grep PrivateTmp

# For PHP-FPM
systemctl show php-fpm | grep PrivateTmp

If PrivateTmp is enabled (value=1), disable it in the service file:

# Create override directory if it doesn't exist
sudo mkdir -p /etc/systemd/system/httpd.service.d

# Create override file
sudo nano /etc/systemd/system/httpd.service.d/privatetmp.conf

Add the following content:

[Service]
PrivateTmp=false

Then reload and restart:

# Reload systemd and restart the service
sudo systemctl daemon-reload
sudo systemctl restart httpd
# or
sudo systemctl restart apache2

Step 4: Verify PHP Temporary Directory Configuration

Check which temporary directory PHP is using:

Create a PHP info file:

echo '<?php phpinfo(); ?>' > /var/www/html/info.php

Visit http://your-server-ip/info.php in your browser and search for:

upload_tmp_dir
sys_get_temp_dir
session.save_path

Ensure these directories are writable by the web server user:

# Check ownership
ls -ld /tmp

# Fix ownership if needed
sudo chown www-data:www-data /tmp  # Debian/Ubuntu
# or
sudo chown apache:apache /tmp      # CentOS/RHEL

# Fix permissions
sudo chmod 1777 /tmp

Important: Clean up after troubleshooting:

rm /var/www/html/info.php

Step 5: Check open_basedir restrictions

If the above steps don't resolve the issue, check if PHP's open_basedir is restricting access to the temp directory:

# Check open_basedir in php.ini
grep open_basedir /etc/php/*/apache2/php.ini
# or
grep open_basedir /etc/php.ini

Ensure the temp directory is included in the list, e.g.:

open_basedir = /var/www/html:/tmp:/var/tmp

/dev/shm Filesystem Capacity Issues

After a period of operation, user sessions may start logging out and new logins become impossible. This occurs when the /dev/shm filesystem (tmpfs) reaches its capacity limit. The VoIPmonitor GUI stores PHP session files in /dev/shm by default for performance reasons.

Symptoms

Users are frequently logged out from the GUI
New logins fail or immediately redirect to login screen
/dev/shm is reported as full (100% capacity)
GUI behavior improves temporarily after clearing session files

Diagnosis

Check the current /dev/shm usage:

# Check /dev/shm usage and available space
df -h /dev/shm

# Check how much space is used by session files
du -sh /dev/shm/php_sessions/*

# Count session files
ls /dev/shm/php_sessions/ | wc -l

Solution: Increase /dev/shm Size

Temporary Increase (Until Reboot)

To temporarily increase the size of /dev/shm without rebooting:

# Remount /dev/shm with increased size (example: 1GB)
mount -o remount,size=1G /dev/shm

# Verify the new size
df -h /dev/shm

Adjust the size parameter (size=1G) based on your server's RAM and expected number of concurrent users.

Permanent Configuration (Persistent After Reboot)

To make the size increase permanent, edit the /etc/fstab file:

# Edit /etc/fstab as root
sudo nano /etc/fstab

Find the line for /dev/shm. It typically looks like this:

tmpfs /dev/shm tmpfs defaults 0 0

Modify it to include the size parameter:

tmpfs /dev/shm tmpfs defaults,size=1G 0 0

Save the file and apply the changes without rebooting:

# Remount all filesystems from /etc/fstab
mount -a

# Verify the new size
df -h /dev/shm

Prevention: Session Cleanup Configuration

Ensure that PHP is configured to clean up old session files from /dev/shm. Check the following PHP configuration settings:

# Check session configuration
php -i | grep -i session

# Look for these directives in php.ini:
# session.gc_maxlifetime - Session lifetime in seconds (default: 1440 = 24 minutes)
# session.gc_probability - Probability of garbage collection (default: 0)
# session.gc_divisor - Garbage collection divisor (default: 1000)

For automatic cleanup, ensure session.gc_probability is set to a non-zero value. The probability is calculated as gc_probability / gc_divisor. For example:

session.gc_probability = 1 and session.gc_divisor = 100 = 1% chance each session start
session.gc_probability = 1 and session.gc_divisor = 10 = 10% chance each session start

Related Information

/dev/shm is a tmpfs filesystem backed by RAM
Increasing /dev/shm size consumes physical RAM - monitor total memory usage
The GUI typically stores session files in /dev/shm/php_sessions/ when configured for performance
Alternative session handlers (memcached, redis) can be considered for very high-traffic deployments

Alternative: MySQL General Log

If you need a persistent server-side log of all database queries (not just from the GUI), you can enable the MySQL general log:

-- Enable general log
SET GLOBAL general_log = 'ON';

-- Perform actions in the GUI...

-- Disable when done (important for performance)
SET GLOBAL general_log = 'OFF';

The log file location is typically /var/lib/mysql/hostname.log or as defined in your MySQL configuration.

Warning: The general log can grow very quickly on a busy system. Always disable it after debugging.

AI Summary for RAG

Summary: This page covers GUI troubleshooting techniques including debug mode activation, MySQL/MariaDB database corruption restoration from PCAP files, incorrect ownership errors caused by missing execute permissions on GUI binaries in the ./bin directory, incorrect web root directory ownership causing "Invalid compressed data in update file" error, RRD graph errors after hardware upgrades (No DS errors in RRD files), upgrade issues (web portal inaccessible after upgrade requiring web server restart, blank screen with JavaScript errors, conflicting constants.php file, apilicensecheck.php fatal error requiring patched file), IonCube Loader problems with temp directory permissions, SELinux, AppArmor, and systemd PrivateTmp, and /dev/shm filesystem capacity issues causing session logout problems.

Keywords: GUI troubleshooting, debug mode, MySQL corruption, MariaDB corruption, database restore, PCAP restore, CDR restore, incorrect ownership, permission errors, bin directory, execute permissions, chmod +x, sox-x86_64, ffmpeg, symlinks, web root ownership, chown -R, Invalid compressed data in update file, web server user, apache, www-data, nginx, directory ownership fix, update fails, RRD graphs, RRD error, Round Robin Database, hardware upgrade, No DS called, delete RRD files, systemctl stop voipmonitor, upgrade issues, web portal inaccessible, restart httpd, restart apache2, restart php-fpm, systemctl restart, IonCube, SELinux, AppArmor, PrivateTmp, temporary directory, permissions, open_basedir, blank screen, JavaScript errors, constants.php, PEAR, ReferenceError, /dev/shm, dev shm, tmpfs, session logout, login failed, mount -o remount, fstab, session gc, session.gc_maxlifetime, session.gc_probability, php_sessions, apilicensecheck.php, findExecutableFile, patched file, license check API, Check License, undefined function

Key Questions:

How do I enable debug mode in the GUI to see SQL queries?
GUI update fails with "Invalid compressed data in update file" - what do I do?
The GUI reports an incorrect ownership error but web server user has permissions - what do I check?
How do I fix incorrect ownership errors related to the bin directory?
What files need execute permissions in the GUI bin directory?
How do I use chmod +x on GUI binaries like sox-x86_64?
Why do GUI binaries need execute permissions?
How do I verify that the web server user can execute binaries in the bin directory?
What should I do if the MySQL/MariaDB database is corrupted?
How do I restore CDR data from PCAP files after database corruption?
RRD graphs show error "No DS called 'SQLq-SM'" after hardware upgrade - how do I fix it?
How do I fix web portal inaccessible after GUI upgrade?
Should I restart the web server after upgrading the GUI?
What web server commands should I use after a GUI upgrade?
How do I fix RRD graph errors appearing after system migration or CPU change?
Can I delete RRD files and will voipmonitor recreate them automatically?
Where are VoIPmonitor RRD files stored?
How do I fix "Unable to create lock file" errors from IonCube Loader?
How do I check if SELinux or AppArmor is blocking the GUI?
What is systemd PrivateTmp and how does it affect the GUI?
Why is my GUI showing a blank screen with JavaScript ReferenceError after an update?
How do I fix ReferenceError: _AuditActivity_download_wav is not defined?
My Check License API call fails with "Call to undefined function findExecutableFile()" - how do I fix it?
How do I fix the apilicensecheck.php fatal error requiring a patched file?
Users are being logged out and cannot login - /dev/shm is full - what do I do?
How do I increase /dev/shm size?
How do I permanently change /dev/shm size in /etc/fstab?
How do I configure PHP to clean up old session files from /dev/shm?