[Linux] after self-update, app relaunches as normal user instead of root (silent privilege change)

[carbone]

I ran into a confusing situation on Linux that I believe was caused by the auto-update relaunch, and wanted to report it.

Setup:
- OS: Arch Linux, local ZFS pool (native mount, no ACLs, no network FS).
- Install: official Linux tarball, installed to /opt/FreeFileSync (/usr/local/bin/freefilesync symlink).
- Version: updated to 14.10 via the built-in updater on Jun 30, 2026.

What happened:

1. I started FreeFileSync as root (via [sudo / a root shell — fill in]), because the sync pair contains root-owned files.

2. FFS offered an update; I accepted and it installed 14.10. The install step clearly ran as root (new files in /opt, symlink in /usr/local/bin recreated, owned by root).

3. FFS relaunched automatically, but the new process was running as my normal user, not root:
ps -eo user:16,pid,comm | grep -i freefile
username 16532 FreeFileSync_x8

4. I didn't notice, and the next sync failed with:
Cannot delete file ".../.github/workflows/release.yml".
EACCES: Permission denied [unlink]

The parent directory is root:root 755, so this is expected for a non-root process. Deleting the file manually as root worked fine, and closing/reopening FFS as root fixed it.

Request:
Dropping root after a privileged install may well be intentional, and I'm not arguing it should keep root. The issue is that the change happened silently. Since the user deliberately started the app elevated, it would help if, when the relaunch would run with a different user/privilege level than the original instance, FFS either:

- shows a notice ("FreeFileSync was restarted as user X, not root"), or
- asks the user to restart it manually instead of relaunching.

For a sync tool, a silent privilege change can lead to partially failed syncs that are easy to misread as permission problems on the disk.

[Zenju]

Fixed for the next release!