The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
You can use an Ubuntu machine as a private SparkleShare host with OpenSSH and Git; there is no separate SparkleShare server daemon in the basic setup. SparkleShare runs on each desktop and synchronizes project folders with Git repositories on the host.
Important: Ubuntu 16.04 and 18.04 are obsolete for standard support. Ubuntu 16.04 standard support ended on April 29, 2021, and Ubuntu 18.04 on May 31, 2023. For a new internet-facing host, choose a currently supported Ubuntu release. This guide is for maintaining an existing Xenial or Bionic machine or testing a legacy setup; package and client compatibility can vary.
How the setup works
SparkleShare desktop client
| SSH, Git and optionally Git LFS
v
Ubuntu host
OpenSSH Server
dedicated Unix account
bare Git repository
SparkleShare provides Dropbox-like folder synchronization backed by Git history. The host is an SSH-accessible Git server, not a web application with a database or administration panel. The project describes its clients as synchronizing local projects with hosted repositories, and says it uses Git and Git LFS underneath. See the SparkleShare project.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
This model suits small groups working with documents, source code, and versioned project files who are comfortable administering SSH. It is not a general cloud drive, online office suite, or backup system. Git history and synchronization do not protect against every deletion, compromised client, repository corruption, or full-disk failure.
#1 Best Overall
Before you install
- Prefer a currently supported 64-bit Ubuntu LTS for a new deployment. Canonical’s Ubuntu support guidance gives the standard-support end dates above. ESM or an isolated legacy host may be appropriate in some environments, but neither makes an old release equivalent to a current installation.
- Give the host a reserved/static IP address and, preferably, a DNS name such as
server.example.com. - Allow inbound SSH on TCP port 22, or on the alternate port you deliberately configure. The basic setup does not need HTTP or HTTPS.
- Plan disk space for working files, repository history, Git LFS objects, and backups. Monitor it: a small working folder can correspond to a much larger repository over time.
- Use a dedicated account such as
sparkleshare, not your administrator login. Keep independent backups of both repositories and Git LFS data, and test restoring them.
Archived images for Ubuntu 16.04.7 and 18.04.6 remain listed on the Ubuntu releases site; their presence does not mean they receive standard support.
1. Install OpenSSH and Git
On the Ubuntu host, install the server packages:
sudo apt update
sudo apt install openssh-server git
Enable and check the SSH service:
sudo systemctl enable ssh
sudo systemctl start ssh
sudo systemctl status ssh
On a typical 16.04 or 18.04 installation, systemctl is available. If it is not, inspect the installed OpenSSH package and the machine’s init system rather than assuming the same service command applies.
Git LFS matters if clients or projects use large-file pointers. Check whether it is available:
git lfs version
If it is missing, install a Git LFS version compatible with the host release, following the project’s installation guidance. Package repositories and supported versions vary, especially on end-of-standard-support Ubuntu releases; do not assume the newest package or current installation script will work on Xenial or Bionic. After installation, initialize Git LFS for the account that will use Git where appropriate:
git lfs install
Git LFS stores large-file content separately from ordinary Git objects, but it still needs compatible client and server support and adequate storage. Frequently changing large binaries can consume substantial space.
2. Create a dedicated account and repository
Create an account for the host-side repositories:
sudo adduser --disabled-password --gecos "" sparkleshare
This creates a normal Unix account; it does not by itself limit SSH users to Git operations. For a small setup with trusted clients, key-only SSH on this dedicated account may be sufficient. If clients are untrusted or you need multiple users and finer controls, use a Git hosting application or configure a carefully restricted Git-only account instead.
Rank #2
Create a repository directory and a bare repository. A bare repository has no checked-out working tree and is the usual form for a central Git remote:
sudo install -d -o sparkleshare -g sparkleshare /srv/sparkleshare
sudo -u sparkleshare git init --bare /srv/sparkleshare/example.git
The corresponding repository path is local to the server. A common SSH reference is:
[email protected]:/srv/sparkleshare/example.git
Some clients accept the explicit form ssh://[email protected]/srv/sparkleshare/example.git; use the syntax accepted by your SparkleShare version. A manually created bare repository demonstrates the underlying Git/SSH arrangement, but it is not a guarantee that every SparkleShare release accepts every repository layout or naming convention.
3. Add and test an SSH key
On each client computer, create a key if you do not already have an appropriate SSH key. On current systems, Ed25519 is a sensible choice:
ssh-keygen -t ed25519 -C "sparkleshare-client"
Very old SSH stacks may not support Ed25519. If you encounter a compatibility problem, use a strong RSA key supported by both ends rather than weakening the server’s general security settings.
Free tools Windows power users keep installed
One-click scans. No signup required.
Copy the public key to the host using ssh-copy-id if available:
Rank #3
ssh-copy-id [email protected]
Alternatively, append the contents of the client’s public-key file (for example, ~/.ssh/id_ed25519.pub) to /home/sparkleshare/.ssh/authorized_keys on the server. Ensure the directory and file belong to the dedicated account and have restrictive permissions:
sudo install -d -m 700 -o sparkleshare -g sparkleshare
/home/sparkleshare/.ssh
sudo chown sparkleshare:sparkleshare
/home/sparkleshare/.ssh/authorized_keys
sudo chmod 600 /home/sparkleshare/.ssh/authorized_keys
Test SSH before configuring the application:
ssh [email protected]
A successful login confirms that SSH authentication works; it does not prove the repository path or SparkleShare project configuration is correct. For more detail when login fails, run:
ssh -v [email protected]
4. Consider the project’s host setup script
The SparkleShare project says it provides a host-setup script to simplify server configuration. Its exact invocation, permissions, repository layout, and user-management behavior are release-specific. Consult the script in the official repository for the release you intend to use before running it; do not guess a command or run a downloaded script with elevated privileges without reviewing what it changes.
In particular, confirm whether it should run as root or as the dedicated account, where it creates repositories, how it installs client keys, whether it configures Git LFS, and how to remove a key or project. Choose either that documented setup or the manual underlying Git arrangement above, then follow the matching client instructions.
5. Install SparkleShare on each client
The project README recommends Flatpak on Ubuntu and Fedora because distribution packages may be old. On a client whose OS and runtime support it, the documented Flathub route is:
flatpak remote-add --if-not-exists flathub
https://flathub.org/repo/flathub.flatpakrepo
flatpak install flathub org.sparkleshare.SparkleShare
Launch SparkleShare from the applications menu. Desktop environments may need AppIndicator support to show its status icon; the project also documents a GTK status-icon option for environments without the expected indicator.
Rank #4
Legacy client caution: A current Flatpak build may not run on the older desktop libraries or graphics stack in Ubuntu 16.04/18.04, while the old distribution package may be outdated. The client does not have to run the same Ubuntu release as the host, but its Git, SSH, repository, and LFS behavior must be compatible. Consider installing the client on a supported desktop OS rather than forcing a new client build onto an EOL machine.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteThe project’s visible release information has shown version 3.38.1 dated September 20, 2024; verify the repository’s releases for the version available now. The README also points readers to issue #2006 concerning the project’s future. Do not assume ongoing maintenance or future compatibility without checking the project’s current status.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.6. Add the hosted project and verify sync
- Start SparkleShare and complete its name/email setup if prompted.
- Choose Add Hosted Project or the equivalent option in your version.
- Enter the SSH host, username, and repository path. UI labels and accepted URL formats can differ by version; use the path and syntax documented for your client.
- Choose a local folder and let the initial clone finish.
- Create a small test file in the synchronized folder. SparkleShare normally handles Git operations automatically; do not manually commit routine files unless troubleshooting.
For example, if the local folder is ~/SparkleShare/example:
cd ~/SparkleShare/example
printf 'SparkleShare testn' > sync-test.txt
git status
Confirm the file reaches a second client. Then test an edit, a deletion, an offline edit followed by reconnection, and—if relevant—a large file using Git LFS. If two users edit the same file at once, especially a binary, expect a conflict that may need manual resolution. Test conflict recovery with disposable data before relying on the service for important files.
Troubleshooting
| Symptom | Likely cause | What to check |
|---|---|---|
Permission denied (publickey) |
Wrong key or account, incorrect .ssh ownership/modes, wrong key selected, or server SSH configuration |
Run ssh -v; verify the public key is in the right account’s authorized_keys, check permissions, DNS, port/firewall, and that public-key authentication is enabled. |
| SSH works, but the project cannot be added | Wrong repository path or URL form | Confirm the bare repository exists and use the exact syntax accepted by the client. Test the path with Git over SSH where possible. |
| Clone succeeds but pushes fail | Repository ownership or write permissions are wrong | Check that the repository and parent directory permit the sparkleshare account to write. |
| Git LFS objects fail to transfer | Git LFS is absent, incompatible, or not configured on one side | Run git lfs version on relevant systems and confirm compatible LFS support and storage. |
| No tray/status icon | Desktop environment lacks the expected AppIndicator support | Install suitable AppIndicator support or use the GTK status-icon option documented by the project. |
| Client will not install or launch | Legacy OS libraries or unsupported Flatpak runtime | Prefer a supported client OS; use an older compatible client only as a temporary, assessed workaround. |
| Unexpected duplicates or conflicts | Concurrent edits or filename/filesystem differences | Resolve carefully; avoid concurrent edits to the same binary and account for case sensitivity, renames, permissions, and symlinks. |
| Disk usage rises unexpectedly | Git history and LFS objects accumulate | Monitor repository and LFS storage, set retention expectations, and maintain independent backups. |
Backups, access, and migration
Back up the bare repositories and any Git LFS object storage, not just the visible project folders. Keep at least one copy outside the host, protect it from routine client credentials, and periodically restore a repository into a test location. SSH encrypts the connection, but does not provide end-to-end encryption, safe backups, or immunity from a compromised account or client.
Revoke access by removing the relevant public key from the account’s authorized_keys (or by using the access-control mechanism of your host script or Git service). Plan an OS migration: copy and verify repositories and LFS data, configure access on a supported host, then test clients before retiring the old server. Do not modify a live repository by casually editing its internal files with a file manager.
Quick Recap
When another tool is a better fit
- GitLab Community Edition: The SparkleShare project recommends it when many projects or users need management. It adds web administration, permissions, and broader repository features, at considerably higher resource and maintenance cost than a bare SSH/Git host. See GitLab installation.
- Gitea or Forgejo: Lightweight Git hosting with a web interface and user management, but still Git hosting rather than a general cloud drive. See Gitea and Forgejo.
- Nextcloud or Seafile: Better candidates for browser access, sharing links, mobile-oriented cloud storage, and broader collaboration features, with more server components to operate. See Nextcloud and Seafile.
- Syncthing: A strong fit for ordinary folder synchronization between devices without a central Git repository. It does not provide SparkleShare’s Git-backed project history. See Syncthing.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

