Syncovery Support Forum

Claude says:

The issue is almost certainly that SELinux doesn't recognize port 8999 as a port your service is allowed to bind to. You can fix it by labeling the port.

For a standard HTTP-type listener, add the port to the `http_port_t` type:

If it already exists with a different type, use `-m` (modify) instead of `-a` (add):
If `semanage` isn't installed:
To verify it worked:
---

Before assuming SELinux is the cause, confirm it. Check the audit log after a failed start:
or
If you see an AVC denial mentioning `name_bind` and port 8999, SELinux is indeed the culprit, and the `semanage port` command above resolves it. If you see no denials, the problem lies elsewhere (e.g. the systemd unit, working directory, or a different permission).

A couple of things worth checking depending on how SyncoveryCL is being launched:

If it runs as a **systemd service**, also confirm the unit has `WantedBy=multi-user.target` and is enabled (`sudo systemctl enable syncoverycl`), and that `Restart=` is set so it survives. A service that "doesn't stay running" can also be a unit that simply isn't enabled at boot, independent of SELinux.

If SyncoveryCL writes to a non-standard directory or PID file, SELinux may also deny that — the `ausearch` output will show it.

You can also temporarily test the SELinux hypothesis without changing policy:
Start the service, see if it binds. Then `sudo setenforce 1` and apply the proper `semanage` fix rather than leaving SELinux permissive.

(right after reboot)
returns nothing.
Also, I had already tried the setenforce and that didn't help either.
I'm wondering if it's really SELinux that's causing the issue. After login, I can even start SyncoveryCL without sudo and it works (my account has access to all folders to be synced). Wouldn't SELinux block that too?

Hi,
OK so it's really not SELinux. Possibly something else that doesn't work at startup.

I'm really going to have to test it myself. I don't have an answer today.

Maybe you can live with starting it manually for a short while.

Sure. No problem.
Syncovery was running fine on Kubuntu and still is running without issues on Windows 11 and on my UGreen NAS. I really like it.

I just noticed that, even when it's running (started with sudo or not), realtime sync doesn't work. No changes are detected, except in manual or scheduled runs.
It can't be a system limitation of Fedora 44 KDE, because RealTimeSync (from FreeFileSync) automatically detects changes and synchronizes accordingly (on the same computer).

Yes, realtime is not supported on Linux.

I hope to add it in Syncovery 12.

tobias wrote: Fri Jun 19, 2026 7:21 pm Yes, realtime is not supported on Linux.

I hope to add it in Syncovery 12.

Ah, ok. Thanks!

In fact you can, for example, do real-time downloads from Google Drive or Dropbox (with around 1 minute delay).

I will add local real-time on the source side ASAP.

I also had an issue when I was using Fedora. I had to disable SELinux to get Syncovery to work. After disabling SELinux there were no issues with running Syncovery.

DenalB wrote: Sun Jun 21, 2026 11:31 am I also had an issue when I was using Fedora. I had to disable SELinux to get Syncovery to work. After disabling SELinux there were no issues with running Syncovery.

I still haven't really understood what SELinux exactly does and how it can be easily configured (i.e. without several days of training in Linux internals, command line stuf, etc). It sometimes throws warning message which are literally chinese to me, so I can't really do anything with them.