I have folders that sit on an encrypted zpool. It doesn’t get mounted automatically on reboot because the encryption keys aren’t stored on the machine. The pool mounts at /tank and syncthing is configured to sync folders like /tank/accounting, /tank/human-resources, etc…
When the system boots, syncthing automatically starts and automatically creates /tank/accounting, /tank/human-resources, etc…and automatically starts syncing them as if they had never been synced before.
Additionally when our tool connects out to the server and decrypts/mounts the drives, the folders fail to mount because syncthing has already created files and folders in their mountpoints.
Is there a way to tell syncthing to make sure that /tank is mounted or that the folders should already exist and not to create them?
Syncthing only does that when there’s no info about the folders in the database, that is, when they are initially added. If you’re seeing something else, something else is going on.
I’ve also observed the folder creation but in a different way when I set up my zpool some weeks ago. It (re)created the folders below the unmounted empty mount point folder where they shouldn’t be and then the folders had the stopped state. That’s because syncthing only recreated the folder root but not .stfolder.
I’ll have to run a few more tests I guess…but I’ve run into a few situations where the folders are completely empty and ZFS hasn’t mounted, then syncthing starts up and begins syncing like it’s a new setup.
I have to stop syncthing, rm -rf the folders, import/mount the zpool, and then start syncthing back up.
Actually if you have nothing at all in the dir it’s clear how/why it happens. It’s not a bug, it’s just a limitation of how it’s implemented currently. It’s easy to improve, so please file an enhancement request on github and I’ll file the PR
I just tested.
When using native encryption on ZFS, zfs creates the mountpoints but there’s nothing in them.
i.e. /tank/accounting, /tank/isostore, etc…
Syncthing starts up and creates /tank/accounting/.stfolder and /tank/isostore/.stfolder.
When we run zfs load-key -a to unlock and mount the pool, the mount fails because syncthing created the .stfolders inside the mountpoints.
We have to manually unlock the pool because we don’t store the key material on the box for obvious security reasons, is there a way to prevent syncthing from touching those folders?
Proxmox has an option to flag a folder as being a ‘mountpoint’ so Proxmox won’t touch it until after a filesystem has been mounted.
This PR (https://github.com/syncthing/syncthing/pull/6626) will still create a folder marker when the folder is newly added, but will not anymore add it if restarted and the folder is empty. I don’t anymore think this needs an issue, it’s a tiny enough change.
Sorry, not happening for now. The quick solution I made has drawbacks (see PR) and given this problem is very niche and has a clear/doable workaround (just make sure you mount before starting syncthing or create something in the syncthing folder the first time around) I am not willing to spend more time on it.
