Troubleshooting — Windows (Task Worker)

Overview

On Windows, Diskover runs only the Task Worker (diskoverd). The full Diskover stack (Elasticsearch, nginx, diskover-admin, diskover-web) must be running on a separate Linux host that this Windows worker connects to.

The Task Worker is installed via the DiskoverTaskWorker.exe installer and runs as a Windows service managed by NSSM (Non-Sucking Service Manager).

Installation Paths

Note on %APPDATA%: This path resolves to the AppData folder of the user who ran the installer. If the NSSM service runs as a different user (or Local System Account), the config file may be in the wrong location. See Config File in Wrong Location below.

Service Management

The Task Worker runs as a Windows service named diskover, managed via NSSM. Run these from an Administrator command prompt:

# Start
nssm start diskover

# Stop
nssm stop diskover

# Restart
nssm restart diskover

# Check status
nssm status diskover

The service can also be managed from Windows Services (services.msc) — look for diskover.

Log Locations

# Tail service error log
Get-Content -Path "C:\Program Files\Diskover\logs\service-start-error.log" -Tail 25 -Wait

# Tail crawl subprocess log
Get-Content -Path "C:\Program Files\Diskover\logs\diskoverd_subproc_$env:COMPUTERNAME.log" -Tail 25 -Wait

Start with service-start-error.log for service-level issues. Switch to the subprocess log for task-specific failures.

Post-Install Configuration

1. Bind the Service to a User Account

After installation, the NSSM service must be bound to a user account that has access to the network shares Diskover will scan:

# Get current user
whoami

# Open NSSM service editor
nssm edit diskover

In the NSSM editor, go to the Log On tab, select This Account, enter the output of whoami and the account password, then click Edit Service.

2. Configure the Worker in Diskover Admin

Once the service has started and the worker appears:

1. Navigate to Diskover Admin > Configuration > DiskoverD

2. Click on the machine hostname

3. Verify settings and save

Troubleshooting

Python Opens the Microsoft Store Instead of Running

Windows has a built-in app execution alias that redirects python and python3 commands to the Microsoft Store, even when Python is already installed. This will cause the Diskover service to fail.

To fix: search for "Manage App Execution Aliases" in the Windows search bar, then find python and python3 and set both to Off.

Worker Not Appearing in Diskover Admin

The service started but the worker is not showing in Diskover Admin > Configuration > DiskoverD.

Check the service error log:

Get-Content -Path "C:\Program Files\Diskover\logs\service-start-error.log" -Tail 50

Look for a line similar to:

Could not connect to api server. Check the values of ['apiurl', 'apiuser', 'apipass'] in C:\...\diskoverd\config.yaml

This will also tell you exactly which config.yaml path the service is trying to read — use this to confirm the config is in the right location.

Verify the Diskover Web URL in config.yaml is correct:

notepad "$env:APPDATA\diskoverd\config.yaml"

Ensure apiUrl points to the Diskover Web host, not localhost:

apiUrl: http://<diskover-web-host>:8000/api.php

Config File in Wrong Location

The installer places config.yaml in %APPDATA%\diskoverd\ for the user who ran the installer. If NSSM is configured to run the service as a different user — or as the Local System Account — the service will look for the config in a different location.

The correct config path for Local System Account is:

C:\WINDOWS\system32\config\systemprofile\AppData\Roaming\diskoverd\config.yaml

To fix, copy the existing config to the correct location:

$dest = "C:\WINDOWS\system32\config\systemprofile\AppData\Roaming\diskoverd"
New-Item -ItemType Directory -Force -Path $dest
Copy-Item "$env:APPDATA\diskoverd\config.yaml" "$dest\config.yaml"

AD Domain User Issues with NSSM

When the Windows machine is joined to an Active Directory domain, NSSM may fail to resolve the domain user's SID when configuring the Log On account. This can prevent the service from starting.

If this occurs, use the Local System Account in the NSSM Log On tab instead, then move the config file to the Local System Account path as described above.

Task Fails Immediately

The worker accepted the task but the crawl process exited without completing.

Check the subprocess log:

Get-Content -Path "C:\Program Files\Diskover\logs\diskoverd_subproc_$env:COMPUTERNAME.log" -Tail 100

For more detail, increase the log level to DEBUG in Diskover Admin > Configuration > DiskoverD > , then retry the task.

Common causes:

• The path being scanned is not accessible by the user running the service

• Elasticsearch is unreachable from this machine — test: curl http://<es-host>:9200/_cluster/health

• Python not found or python.exe is aliased to Microsoft Store (see above)

Connecting to a Single-Stack OVA

If the Diskover stack is running on a single OVA, the DiskoverD configuration for the Elasticsearch connection is likely set to localhost. This must be changed to the OVA's IPv4 address so the Windows Task Worker can fetch the ES configuration and connect properly.

Navigate to Diskover Admin > Configuration > Diskover > Elasticsearch and update the Elasticsearch host from localhost to the OVA's IP.

Running a Manual Scan

To test indexing without going through the task queue, open an Administrator command prompt:

cd "C:\Program Files\Diskover"
python diskover.py -i diskover-<indexname> "C:\path\to\scan"

Note: All index names must start with diskover-.

Log Management and Rotation

Windows has no built-in log rotation. Left unmanaged, Diskover log files — particularly the crawl subprocess log — can grow large on active workers.

Log files to monitor:

Diskover Admin Log Settings

The crawl subprocess log respects the log rotation settings configured in Diskover Admin > Configuration > DiskoverD > . Set a max file size and backup count to limit growth. The default is 100 MB with 1 backup.

NSSM Service Logs

The service-start.log and service-start-error.log files are written directly by NSSM and are not subject to Diskover's log rotation. These must be managed manually or via a scheduled task.

Manual cleanup (Administrator PowerShell):

# Clear NSSM service logs (stop service first to avoid file lock)
nssm stop diskover
Clear-Content "C:\Program Files\Diskover\logs\service-start.log"
Clear-Content "C:\Program Files\Diskover\logs\service-start-error.log"
nssm start diskover

Automated Cleanup with Task Scheduler

You can automate log cleanup by creating a scheduled custom task that runs the following PowerShell script on a recurring basis (e.g., weekly):

$logDir = "C:\Program Files\Diskover\logs"
$maxAgeDays = 30

Get-ChildItem -Path $logDir -Filter "*.log" | Where-Object {
    $_.LastWriteTime -lt (Get-Date).AddDays(-$maxAgeDays)
} | Remove-Item -Force

Save as a .ps1 file and schedule via Task Panel > Create Custom Task, set the schedule to weekly, and set the action to run powershell.exe with -File "C:\path\to\script.ps1". Adjust $maxAgeDays = 30 in the script as needed for retention.

Reinstalling Python Dependencies

If the Task Worker fails to start with ModuleNotFoundError or similar import errors, reinstalling the Python dependencies can resolve the issue. This is also required after a Diskover upgrade that introduces new package requirements.

On Windows, Python is installed per-user under %localappdata%\Programs\Python\Python311\. Run the following from an Administrator command prompt:

& "$env:LOCALAPPDATA\Programs\Python\Python311\python.exe" -m pip install -r "C:\Program Files\Diskover\requirements.txt"

After reinstalling, restart the service:

nssm restart diskover

If the python.exe path above doesn't resolve, confirm the install location:

where python

Checking the NSSM Service Configuration

To view the full current NSSM configuration for the Diskover service:

nssm dump diskover

This outputs all configured parameters including the executable path, working directory, log paths, and Log On account.