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.
Thank you all again for your support.
No why would you do that don’t override PATH for the container… ah well if it works.
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. Cheers
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.
I’m not quite sure what your question is, but maybe a clarification helps here: The upgrade code contains migration routines for each version to the following. When things change, another entry is just appended to that list, so all previous migrations are run just as they were introduced in the past, before the most recent one gets its turn. So in theory, it should not matter whether you do incremental upgrades, migrating the DB each time, or just jump to the latest version and let it run through the same migration steps.
In practice, there may be subtle bugs if internal data structures are changed without considering that the migration code needs the old definition. But we take great care to keep backwards compatibility where possible and I think such a breaking change would get noticed during review. That said, of course the risk increases gradually because usually no one tests whether all these large version jumps actually work 100% correct.
I haven’t seen anywhere how many Devices and Folders are implemented. Given the uncertainty and if there are a few at a time, it may be more time-saving to start from scratch than to try and maybe tinker.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.