The core issue is that you can’t directly see the original filenames because everything is encrypted, so deleting blindly is risky.
I put together a small Bash script, st-enc-prune.sh, that uses Syncthing’s decrypt --verify-only --verbose command to map encrypted files back to their plaintext paths. You can then choose which files to delete. Some key points about what it does:
Lets you filter files by glob (-m) or regex (-r)
Supports interactive deletion, or deleting everything that matches without prompting
Has a dry-run mode to check what would be deleted first
Cleans up empty directories after removing files
It’s worth emphasizing that this script does not decrypt the file contents, only identifies which encrypted files correspond to which plaintext paths. That makes it safe to use even on untrusted devices, as the actual data stays encrypted.
Some caveats to keep in mind:
Always test with dry-run mode before deleting anything
The script relies on the current decrypt command output format to identify plaintext filenames. This means it could break not only if the decrypt command changes in future Syncthing releases, but also if the log/output format changes. It has been tested on v2.0.12, Linux (64-bit ARM) – “Hafnium Hornet” Build 2025-11-25, and should also work on v2.0.5, Windows (64-bit Intel/AMD) – “Hafnium Hornet” Build 2025-09-03, as the output format is effectively identical.
Folder structure in .stversions is hashed, so you can’t rely on it mirroring the original paths—deletion is done at the file level, not by reconstructing directories.
Use at own risk (.sh code is provided and visible, ensure you use -n/–dry-run first for testing)
For anyone dealing with bloated remote encrypted .stversions due to misapplied ignore rules or large files, this approach seems to be a controlled way to prune only the unwanted items without touching the rest.
A more secure approach could be to generate the encrypted paths on a trusted device (which already has the folder password), then send that list over to the untrusted peer to delete.
That all depends on what the threat model is. There’s a big difference between “the device is under the control of an attacker who can monitor every keystroke sent over ssh and understands syncthing encryption” and “the data at rest shouldn’t be accessible by the otherwise trusted cloud provider”.
Good point - but that limitation isnt specific to the script (or Syncthings decrypt command). It applies to any tool or application that uses a secret on such a system. If the host can observe keystrokes, memory, processes, etc., theres no way to securely provide a password there.
That kind of threat is mostly outside the scope of this script (and I would assume Syncthing itself - how else would you access encrypted files on such a server, except to copy or move them to a safe system? I dont think Syncthing allows for a dir-tree/file mirror of encrypted filename 0 byte files to be worked on, as it requires the encrypted file data as well for decyrpt….afaik). In environments where the host cannot be trusted at all with any secrets, the only safe approach is to run the decrypt step on a trusted system and then apply the resulting encrypted-path deletions remotely. Doing that would introduce significant transfer costs just to delete selected files. Its possible to script, but its currently outside the scope of this script. I can update the OP to clarify this if that would help.
Indeed, different threats need to be considered here. If the data at rest is encrypted, it’s still very easy to passively keep a copy for later decryption. Much more effort is needed to record keystrokes and actively exfiltrate passwords from that. What I was hinting at would be the obvious mistake of entering the folder password as a command line parameter, which would likely be stored in the shell history. At that point, a plain copy would contain both the encrypted data and the decryption password.
Maybe stating the obvious, but it’s a common mistake to be aware of and avoid.
Yep. Well this aligns with Syncthing itself. I should have probably stated that the script treats passwords by first checking for an existing environment variable or password file (usually found on safe systems). If neither exists, it prompts interactively (not recorded in bash/CLI history). The env/file options are purely for flexibility and intended only for trusted systems. There is no option to provide the password directly as a command-line argument, although someone might assume otherwise if they don’t read the help (-h/–help) text first.