Nextcloud Client on Chromebook (ARM/aarch64): Solving Two-Way Sync

Short explanation on how to get the Nextcloud Linux desktop client working reliably on a Chromebook. This solution is necessary because the official Android desktop client does not offer true two-way synchronization, which is a critical feature for managing files across systems.

The Problem: Lack of Two-Way Sync

I was disappointed to find this synchronization gap. Currently, when files are deleted on my Nextcloud server, they are not deleted locally on the Chromebook—a functionality I need for core folders like Documents, Downloads, and Projects. My research confirmed this is a persistent issue, as shown in the following issue tracker entries:

https://github.com/nextcloud/android/issues/11470
https://github.com/nextcloud/android/issues/19
https://github.com/nextcloud/android/issues/285

The primary workaround is to bypass the Android application entirely and run the dedicated Linux desktop client within the Chromebook’s integrated Linux environment (Crostini).

Critical Security Trade-offs

The primary challenge for this workaround involves security. Running the Linux client requires access to the files you want to sync, which means you must grant the Linux VM and the Flatpak application access to core folders.

Filesystem Exposure: You’ll have to grant the Linux VM access to all synchronized folders. Within the VM, they’ll be located in /mnt/chromeos.
Flatpak Sandbox: The Flatpak sandboxing is severely weakened when you grant it host file access. This breaks the intended security model.

Autostart Workaround: While no official fix exists, the most reliable method for automated start involves creating a custom Systemd user service unit or a wrapper script that is executed after the Linux VM starts.

Variant #1: Linux DEB / APT (Stability First)

This method relies on the stable package provided by the Debian/Ubuntu repositories.

# Install the package
apt-get install nextcloud-desktop

# Run with the -l parameter if the window fails to appear initially
nextcloud -l

# Verification (Example Output on ARM64)
jean@penguin:~$ nextcloud -v
Nextcloud version 3.1.1-2+deb11u1
...
Running on Debian GNU/Linux 11 (bullseye), arm64

Variant #2: Linux Flatpak (Latest Features & Hardening)

For those who prioritize the latest features and bug fixes, the Flatpak variant is the superior choice.

# 1. Install Flatpak
sudo apt-get install flatpak

# 2. Add the Flathub repository
jean@penguin:~$ flatpak --user remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

# 3. Install the Nextcloud Desktop Client
jean@penguin:~$ flatpak install flathub com.nextcloud.desktopclient.nextcloud

Flatpak Security Audit and Access Restriction

When installing, Flatpak explicitly lists the permissions. The permission file access [1] host is the security compromise, as it grants the application access to your host filesystem, bypassing the isolation.

To harden the setup, restrict the Flatpak filesystem access to the bare minimum.

Stop the Client: Ensure the client isn’t running.
Use flatpak override: Instead of relying on the broad host access, explicitly grant access only to the necessary ChromeOS-mounted sync directories.

# Check the current permissions (will likely show "filesystem=host" or "filesystem=home")
flatpak info --show-permissions com.nextcloud.desktopclient.nextcloud

# OVERRIDE: Set explicit read/write access ONLY to the required sync folders
# Example: Assuming your Documents are synchronized to /mnt/chromeos/GoogleDrive/Documents
flatpak override --user com.nextcloud.desktopclient.nextcloud \
    --filesystem=/mnt/chromeos/GoogleDrive/Documents:rw \
    --nofilesystem=host

Note: By using --nofilesystem=host and providing --filesystem=/specific/path:rw, you override the broad permission with a restrictive one, significantly improving the security posture of your Linux VM.

Variant #3: AppImage (The X86_64 Option)

While the ARM AppImage variant is unavailable, it remains a simple option for users running Intel/AMD (x86_64) architecture. Simply download the AppImage file, make it executable, and run it from the Linux VM.

Summary

The synchronization functionality I required for my core folders is only reliably achieved via the Linux Desktop Client. While the Android client offers better integration, the inability to perform full two-way synchronization made it unsuitable for my productivity needs. The security trade-off is manageable by applying strict Flatpak overrides.