SYNC push mode: device data is silently never sent — sync.py reads a path that doesn't exist in the Docker image

[saargilat]

What installation are you running?

Production (netalertx) 📦

Is there an existing issue for this?

• I have searched the existing open and closed issues and I checked the docs https://docs.netalertx.com/

The issue occurs in the following browsers. Select at least 2.

• Firefox
• Chrome
• Edge
• Safari (unsupported) - PRs welcome
• N/A - This is an issue with the backend

Current Behavior

In push mode (node → hub, with SYNC_hub_url and SYNC_devices=True set on the node), the node never sends device data — silently. The log shows "Mode 1: PUSH (NODE)" and then nothing: no send attempt, no error, no hint. The hub receives nothing.

Root cause: front/plugins/sync/sync.py builds the source path as f"{INSTALL_PATH}/api/table_devices.json" (→ /app/api/table_devices.json), but in the Docker image the API JSON files are written to NETALERTX_API=/tmp/api and /app/api does not exist. The read is guarded by if os.path.exists(file_path): with no else branch, so the push is skipped without a trace. Observed on v26.2.6 and code-verified still present on current main (sync.py line ~109). The hub-side GET handler in server/api_server/sync_endpoint.py already does this correctly via os.environ.get('NETALERTX_API', '/tmp/api').

Expected Behavior

Device data is pushed to the hub after each scan. If the source file is missing, a log line should say so instead of failing silently.

Suggested fix (sync.py):
api_path = os.environ.get('NETALERTX_API', '/tmp/api')
file_path = f"{api_path}/table_devices.json"
plus an else-branch logging that the file was not found.

Steps To Reproduce

1. Two Docker instances of NetAlertX (node: RPi4/arm64, hub: arm64), matching API_TOKEN and SYNC_encryption_key
2. On the node set: SYNC_hub_url='http://:20212', SYNC_devices=True, SYNC_RUN='always_after_scan'
3. Verify inside the node container: /tmp/api/table_devices.json exists, /app/api does not (os.path.exists returns False)
4. Run the plugin: docker exec netalertx python3 /app/front/plugins/sync/sync.py
5. Observe: "Mode 1: PUSH (NODE)" is logged, then nothing — no request reaches the hub
6. Workaround proof: docker exec netalertx ln -s /tmp/api /app/api → the very next run logs "sent successfully" and the hub receives the devices

Relevant app.conf settings

SYNC_RUN='always_after_scan'
SYNC_devices=True
SYNC_plugins=[]
SYNC_node_name='NAX-abcdefab'
SYNC_encryption_key='<redacted>'
API_TOKEN='<redacted>'
SCAN_SUBNETS=['192.168.1.0/24 --interface=eth0']

docker-compose.yml

# equivalent docker run (node, Raspberry Pi 4 / Debian 12 arm64):
# docker run -d --name netalertx --network host --restart unless-stopped \
#   -e TZ=America/Los_Angeles -e PORT=20211 \
#   -v <PATH>/netalertx/data:/data \
#   ghcr.io/jokob-sk/netalertx:latest   # v26.2.6

Debug or Trace enabled

• I have read and followed the steps in the wiki link above and provided the required debug logs and the log section covers the time when the issue occurs.

Relevant app.log section

Captured with LOG_LEVEL='debug'. Filesystem state verified immediately before the run:

/app/api/table_devices.json exists: False (while /tmp/api/table_devices.json exists: True)

00:13:57 [SYNC] In script
00:13:57 [SYNC] Mode 1: PUSH (NODE) - This is a NODE as SYNC_hub_url, SYNC_devices or SYNC_plugins are set
00:13:57 [SYNC] plugins_to_sync []
<no further SYNC output — script exits, nothing is sent, no error at any log level>

For contrast, the same run after ln -s /tmp/api /app/api:
00:14:09 [SYNC] Tried endpoint: http://:20212/sync, status: 200
00:14:09 [SYNC] Data for "/app/api/table_devices.json" sent successfully via http://:20212/sync

Note: the plugin messages in this code path are emitted at verbose level; debug adds no extra
output here — the defining symptom is the absence of any send/error after "Mode 1".

Docker Logs

--> expected user id match.sh
--> host mode network.sh
--> excessive capabilities.sh
--> appliance integrity.sh
--> ports available.sh
Starting supercronic --quiet "/services/config/cron/crontab" >>"/tmp/log/cron.log" 2>&1 &
Starting /usr/sbin/php-fpm83 -y "/services/config/php/php-fpm.conf" -F (tee stderr to app.php_errors.log)
Starting python3 -m server > /tmp/log/stdout.log 2> >(tee /tmp/log/stderr.log >&2)
Starting /usr/sbin/nginx -p "/tmp/run/" -c "/tmp/nginx/active-config/nginx.conf" -g "error_log stderr; error_log /tmp/log/nginx-error.log; daemon off;" &
Successfully updated IEEE OUI database (114848 entries)

(Container startup is clean — the failure itself produces no docker-log output at all;
the silent skip is only visible in app.log, provided above.)

[jokob-sk]

Thansk a lot for the detailed error description. This should be available/fixed in the next release.
It would be great if you could test the ghcr.io/netalertx/netalertx-dev-unsafe Docker image in ~15 minutes (or once the latest GitHub Action finishes).

⚠️ Please back up everything first, or ideally spin up a separate container (make sure you use a unique PORT and GRAPHQL_PORT if running instances concurrently) with its own DB and config (a copy of your current setup), as database changes may occur.

After updating:

• Click the 🔄 refresh button in the blue header at the top
• Hard refresh your browser cache (shift + reload) to force js and css files reload

Disclaimer: Running the dev container long-term may lead to data loss, as upgrade paths are not guaranteed.

Thanks in advance,
j

[jokob-sk]

As a workaround on the latest version, you can send plugin data via the SYNC_plugins setting.

[saargilat]

Tested ghcr.io/netalertx/netalertx-dev-unsafe:next_release in an isolated container
(fresh copy of my DB/config, no symlink workaround present):

Fixed — sync.py now reads /tmp/api/table_devices.json correctly and attempts the
push. Also confirmed the new error logging fires properly when the hub is unreachable
(much better than the old silent skip). Thanks for the fast turnaround!

One note on the suggested workaround: SYNC_plugins unfortunately can't serve as one —
the plugin result files are deleted by the framework before the SYNC plugin runs, so
nothing is ever sent. Filed separately with details: #1699

I'll stay on the stable release + symlink workaround until the next release ships.

[jokob-sk]

Thanks a lot for testing - glad it's working now. I left a comment on #1699 regarding the other issue as well.