Why would you want to stick to an ancient version?
it’s not that I wanted to stick to 1.3.4, there has been so much to life (excluding pandemias, moving home, etc.) I had so many things to think about I let something that worked well do its job by itself for a while…
Yeah, there’s been a shitload of improvements, most of them good. If you want to look for the more important ones, look at the changelog for the .0 releases. Looking just at 1.4.0 that included a big database change that improved life for all larger setups.
You should be fine to go directly from 1.3.4 to 1.20.2. We intended it to be possible to do that. You’ll probably be the first and only to actually try it.
I can understand that such questions arise as it gives a sense of security when software is running smoothly and thinking about to “go away from it”. Feeling safe and thinking about doing an update, but where is the journey going? Others, like me, and probably most here, make all the updates, maybe even the RC’s. Errors occur very rarely, but are quickly rectified. In this respect, I would have good faith that nothing negative would arise.
I wouldn’t be quite sure about such a major step either, but if a database conversion in v1.20.2 works in the same way as with v1.4.0, that would probably be the main thing.
Much more interesting in the new versions are the features that have been added and optimized along with performance and system. In this respect, the update and its exploration is worthwhile in any case.
All right, I can try to update and report back how it went.
I was thinking about giving the Mac the first try then push the upgrade to the Docker container too, so:
if something goes bad on the Mac side at least do you know if can I go back to the 1.3.4 with Time Machine? in that case can you list the folder(s)/settings I have to restore from the TM backup? (I don’t mean the synced folders but the Syncthing app folders)
is there some known issue if the nodes are on different versions? Should I update both at the same time instead?
If you are not quite sure, it would be possible to create a test environment first, maybe better then with other computers?
Otherwise only the backup of the data folder would remain on each device with the config, the key files, as well as the subfolder index-v0.14.0.db with the database, then the v1.3.4 could be reinstalled if necessary and the data folder restored again.
One of the notable additions is “untrusted” devices (where the sync data and file names are encrypted on a remote device, but still properly synchronized), improvements in handling conflicts, improvements in the WebGUI (for example: direct link to edit ignore patterns from the folder status)…
Do the upgrade on both sides – many of the benefits won’t be seen unless both sides talk (close to) the same version.
If you don’t like what you get, replace the files you backed up on both sides and delete the database directory, then restart with the old version. The database will be rebuilt and it will look like the two sides are exchanging a lot of files, but if they were already in sync all you are seeing is the exchange of metadata as the two sides catch up.
No risk at all.
And do let us know how the upgrade goes, its an interesting data point to validate the developers’ efforts at maintaining continuity (a very laudable effort, which I am sure costs no small amount of frustration at times!).
I have been able to successfully upgrade to 1.20.2 on the Mac, but can’t figure how to upgrade Syncthing inside the Docker container on the NAS, it says “upgrade unsupported” when I launch the upgrade command from shell. I checked the env var inside the container and there is no STNOUPGRADE defined, but the hourly auto upgrade (set to 12) does not work too.
How do I upgrade? Originally I installed syncthing/syncthing from QNAP Container Station.
The config and database should always be on a volume outside the container, our docker image and instructions do this by default. If you’re unsure how it’s set up you might want to make sure of that though.
I also have the Docker versions running on my Synology’s. If there are changes in the config, I create an export of the configuration after each change. I haven’t had any changes lately, so I always work with the same configuration.
Since the database and configuration files are then also located natively in the configured directory of the volume, an update is always very quick. Stop and delete the container, delete the image, download the latest image, re-import the new container with the exported configuration and then activate the container. That’s all and is done within a few minutes.
I use QNAP and I think I have been able to install the 1.20.2 on the new Docker container and the config + database is on a share outside of it. I basically keep things as they were working with the 1.3.4 I used up to today on the same mount points.
But when I run the container I get an entrypoint error.
As you may have guessed I am not a Docker expert, so does someone know what this does mean?
I guess I made it, I recreated the Docker container like before but I added /bin/bash to the PATH variable and it started to work. Don’t know if that actually made the difference but I didn’t get the su-exec error anymore.
The overridding content for PATH variable was in some instructional blog I must have found online back in the days I installed Syncthing in Docker for the first time (1.3.4). Since it worked I replicated the values for this upgrade, but with the su-exec error as a result.
Then searching randomly for that error today I found a mention (it was a Docker page) of the bin/bash folder in the path. Well, out of intuition and/or luck, I tried that and yes it worked.
I am not quite the specialist there either. However, this short “folder” normally is a prefix to the actual path, which activates the Bash code for the execution and Bash is in the root subdirectory bin. This effect maybe is then more QNAP specific and has nothing to do with Syncthing. On my Synology’s I just had to integrate the config location and all my shared folders, which I usually use under /volume1/… and since then it works without any such modifications. Only the performance is not quite as good as with native installations.