Syncovery crashing on Fedora

[tobias]

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:

Code: Select all

sudo semanage port -a -t http_port_t -p tcp 8999

If it already exists with a different type, use `-m` (modify) instead of `-a` (add):

Code: Select all

sudo semanage port -m -t http_port_t -p tcp 8999

If `semanage` isn't installed:

Code: Select all

sudo dnf install policycoreutils-python-utils

To verify it worked:

Code: Select all

sudo semanage port -l | grep 8999

---

Before assuming SELinux is the cause, confirm it. Check the audit log after a failed start:

Code: Select all

sudo ausearch -m avc -ts recent

or

Code: Select all

sudo journalctl -t setroubleshoot

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:

Code: Select all

sudo setenforce 0   # permissive mode, temporary until reboot

Start the service, see if it binds. Then `sudo setenforce 1` and apply the proper `semanage` fix rather than leaving SELinux permissive.

[CDR224]

Code: Select all

sudo ausearch -m avc -ts recent

(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?

[tobias]

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.

[CDR224]

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.

[CDR224]

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).

[tobias]

Yes, realtime is not supported on Linux.

I hope to add it in Syncovery 12.

[CDR224]

Yes, realtime is not supported on Linux.

I hope to add it in Syncovery 12.

Ah, ok. Thanks!

[tobias]

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.

[DenalB]

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.

[CDR224]

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.