List of things you liked
- The project’s goals
apt install freedomboxand it’s working!
- Neat UI
List of things you disliked
- Would love to see backups for SAMBA 
DEBIAN_FRONTEND=noninteractive, it was not clear to me the implications of several questions during the installation.
- I found some issues after installation on a fresh Bullseye RC3. I’m describing them below. Let me know if you want me to fill in a bug report elsewhere.
The automatic FreedomBox installer used
subvol=.snapshot to identify the subvolume, but that didn’t work.
UUID=44539a99-4cf0-456b-b4ec-5e94139e8f63 /.snapshots btrfs subvol=.snapshots 0 1
subvolid seemed to work:
UUID=44539a99-4cf0-456b-b4ec-5e94139e8f63 /.snapshots btrfs subvolid=260 0 1
After installation, access to Cockpit was forbidden…
Add more origins to
Origins=https://freedombox https://freedombox.ewlan.es https://freedombox.local https://localhost https://localhost:4430
Change of external SSH backup server fingerprint made any backup configuration involving that server to fail
If an external SSH backup server changes its fingerprint, any attempt to configure backups targeting that host fails. The UI shows an error message (don’t remember which, possibly it was a warning about the fingerprint mismatch) and a success message stating that the fingerprint was correctly stored. Both messages at the same time.
Trying to modify, or create new backup targets involving that host failed with an error and success message.
This is a very exceptional situation, since servers should not change fingerprints frequently. But if it happens, it doesn’t seem possible to update the known host from the UI.
- I configured a backup target in FreedomBox.
- The SSH server changes fingerprint.
- It is no longer possible to configure backups targeting that server from FreedomBox UI.
I had to manually remove the host from plinth’s
Either the backup application or plinth logic should be reviewed in order to cover this situation.
This is probably more a problem in my hardware than a FreedomBox issue. However, it might be interesting if FreedomBox could detect this kind of issues or even set a “safe” default for network interfaces.
During a Borgbackup data transfer, the SSH connection was dropped by the server because of integrity issues.
SSH connection at client side stalled (forever).
Logs at SSH server shown the following message:
ssh_dispatch_run_fatal: Connection from user <U> port <P>: message authentication code incorrect
Switching off hardware offloading solved the issue:
ethtool -K enp1s0 rx off tx off