

How can I get design or consultancy help? There may be other deployments, used for a different purpose, which are not covered by support. Support may be withheld if it is discovered that a significant part of the deployment is not covered by the subscription. How many of my devices do I need to have under support?Įach Syncthing device used as part of the deployment where support is required must be covered by the support subscription. However, your ability to continue to use Syncthing is not affected in any way. Access to the Kastelo support portal will be revoked. What happens when my support expires?Īfter your support contract expires you are no longer eligible to obtain support from Kastelo. Kastelo does not support binaries that you build from source yourself, or binary distributions obtained from other sources. Purchase a Standard or Premium support subscription for each Syncthing device that requires support. Kastelo supports binary builds of the open source Syncthing that are obtained from the official GitHub releases page and the Syncthing APT repository (). How is the open source Syncthing supported? We will offer service credits in the event that we fail to meet this expectation. Go to settings, Global Discovery Server and add stdiscosrv’s host address to the comma-separated list, e.g. What SLA can Kastelo guarantee?įor Premium support customers, Kastelo guarantees an SLA of one hour for the initial contact in new support queries. To make Syncthing use your own instance of stdiscosrv, open up Syncthing’s web GUI. If you have a Premium support subscription, you can get support by phone for critical issues. You can also use the support portal to create and follow up on support tickets. To create a support ticket, please use the email addresses in your support contract to send and receive support case information. We provide technical support for the current release, and any release issued within one year of the current release. We proactively notify all subscribers when important updates are available. We generally advise users to run the most recent version of Syncthing as it is the most up to date and secure. Hope this helps anyone with similar type issue.FAQs Which versions of Syncthing are supported? Bottom line is it seems like OMV forgets the blind mount, or however it creates the share on the DiskPool in the /sharedfolders directory after a reboot. Now on reboot, everything comes back as before the reboot. To fix this I now point the Docker container to the /srv folder where the actual DiskPool "drive" is created. This is why after logging in again it looked like I was starting Syncthing for the first time. However, after a reboot, OMV doesn't recognize the /sharedfolders/ directory as part of the DiskPool and recreates the config folder on the host partition and not the DiskPool. This worked and created the sync folder and config folder for Syncthing on the DiskPool.

After creating the share on the DiskPools, I referenced the share in the Syncthing Docker container by browsing to the /sharedfolders/ directory (where the config directory was created). Turns out there is a bug, or maybe a designed feature, with how OMV handles shared folders under Access Rights Management that are created on DiskPools. Thank you for the suggestion geaves, that led me to figure out what was going on.


This would suggest that the relevant settings aren't being written to the config file, start by looking at the config on the server and also the log of syncthing docker.
