DSM 7.1.1-42962 Update 2

My NAS is wanting to update to DSM 7.1.1-42962 Update 2. There is a warning that the following packages will need an update to a compatible version after the DSM update. Syncthing is in that list of packages: image

I am using the package from SynoCommunity. Does anyone know if it is still working after this update or do I need to look at migration to docker?

Sorry I don’t know as I haven’t tried DSM 7 at all yet. Synology blocked support for a feature from DSM 6 which the package makes use of to automatically manage renewal of certificates for the web GUI. That really dampened my motivation to upgrade.

Other than that, the package does work fine on DSM 7 in general. If that message turns out pointing to a real problem, I guess we will fix it on SynoCommunity.

1 Like

Is the native package that much better than running it in docker? Syncthing is a key part of my workflow but is not very time sensitive.

I also have this exact same issue. My nas is wanting to to install 7.1.1-42962 but suggesting syncthing possibly wont work afterwards.

I don’t know how well it works in Docker, but lots of people have tried and I haven’t heard many complaints about that. It mainly depends on Docker being available for your DiskStation and DSM version at all.

Habe you tried to reach out on SynoCommunity about the warning? Maybe someone there knows what it’s about.

I checked on their Discord server and it did not sound like anyone had tried yet.

@richardwarriner Please reply if you try the update and what you end up finding out. I cannot risk the outage until I have enough time to also get the Docker version up and running so I have that as a failover option.

The Docker version is just as good as the native installation version. The performance of the Docker version may not be as good as with the native version, but I don’t think it matters much, especially since Syncthing is functionally a background process.

I have three Synology and on each are both versions installed with the necessary precautions for it. With this I do any necessary local copies. I have been doing this for a long time and it works very well.

Docker is a bit more involved in terms of implementing shared folders, and UID and GID. Once that is set up once, reinstalling afterwards by image inclusion and container creation is a matter of a few minutes. First follow basically the steps as described

Updates work the same in both cases through internal updates, so that’s very straightforward.

If you already have DSM 7, I suggest you install the Synology APP VMM and install the VM version of DSM 7 and try to install both syncthing versions there under DSM 7.1.1-42962 Update 2 circumstances, then you can test if that runs smoothly for your needs before updating your production system to DSM 7.1.1-42962 Update 2.

Since I still have DSM 6 on all Synology, the newest update is unfortunately not executable, since the current version of the VMM APP is required for it, which is no longer available on DSM 6, otherwise I would have already tested it.

1 Like

I got the docker version working so I had failover if needed and then performed the DSM update. Did not see any issues with the package running after the DSM update. So it will not be an issue going FW I am moving over to the docker version for now.

Thanks

1 Like

So you have the native and docker versions both running and both pointing to the same files on the nas? If I set up docker and point it to the same files I suppose it just sees everything as in sync from the start?

Did you follow any guide for docker? I have absolutely zero knowledge of it other than broadly what it is so anything you could provide would be very useful.

I only ran one at a time and I copied the config for the package over to the docker config so I only had to have it scan and re-create the DB.

I used these two links to go off of:

@JamesTX10 Thanks for this - very useful.

A final question. There seem to be 2 respositories available in Docker, one from syncthing and another from linuxserver.io

The linuxserver one seems more popular. Do you have any comments on which is the one to go for?

Thank for you help on this

I am not a docker guru but I have a few containers running. I always try to go with the official option first and only if I have issues, go with another option. A lot of times someone else wanted the software in docker before the creators took the time to create a docker option but the creators usually update faster and have better support.

All that to say I am using the Syncthing option.

1 Like

No, is not needed and not recommend since I use the second instance for local syncs only.

The difference between the instances are the different ports. Look as follow to a sample of config json and also to the ports:

{
   "cap_add" : [],
   "cap_drop" : [],
   "cmd" : "",
   "cpu_priority" : 50,
   "devices" : null,
   "enable_publish_all_ports" : false,
   "enable_restart_policy" : false,
   "enabled" : true,
   "entrypoint_default" : "/bin/entrypoint.sh /bin/syncthing -home /var/syncthing/config",
   "env_variables" : [
      {
         "key" : "PATH",
         "value" : "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
      },
      {
         "key" : "PUID",
         "value" : "1085"
      },
      {
         "key" : "PGID",
         "value" : "65571"
      },
      {
         "key" : "HOME",
         "value" : "/var/syncthing"
      },
      {
         "key" : "STGUIADDRESS",
         "value" : "0.0.0.0:8384"
      }
   ],
   "exporting" : false,
   "id" : "xxxxxxxxxxxxxxxxxx",
   "image" : "syncthing/syncthing:latest",
   "is_ddsm" : false,
   "is_package" : false,
   "links" : [],
   "memory_limit" : 0,
   "name" : "syncthing-syncthing",
   "network" : [
      {
         "driver" : "bridge",
         "name" : "bridge"
      }
   ],
   "network_mode" : "bridge",
   "port_bindings" : [
      {
         "container_port" : 21027,
         "host_port" : 21029,
         "type" : "udp"
      },
      {
         "container_port" : 22000,
         "host_port" : 22002,
         "type" : "tcp"
      },
      {
         "container_port" : 8384,
         "host_port" : 8386,
         "type" : "tcp"
      }
   ],
   "privileged" : false,
   "shortcut" : {
      "enable_shortcut" : false
   },
   "use_host_network" : false,
   "volume_bindings" : [
      {
         "host_volume_file" : "/music",
         "mount_point" : "/Folders/music/",
         "type" : "rw"
      },
      {
         "host_volume_file" : "/OCRmyPDF",
         "mount_point" : "/Folders/OCRmyPDF/",
         "type" : "rw"
      },
      {
         "host_volume_file" : "/photo",
         "mount_point" : "/Folders/photo/",
         "type" : "rw"
      },
      {
         "host_volume_file" : "/homes/syncthing-dk",
         "mount_point" : "/var/syncthing/",
         "type" : "rw"
      }
   ]
}

I have it up and working in Docker - my first container!

Just a question though - i have seme instructiojns of updating docker contaners with newer images but how does this work with syncthing’s built in updating machanism? Do i need to download a new image each time there is a new syncthing release or can i just forget this one now?

In my docker Syncthing settings > general it says that automatic upgrades are unavailable/disabled by the administrator or maintainer. So it would look like we need to update the docker image in order to update the app. As long as you provided a storage location outside of your container for the SyncThing config to be stored then you should not have any issues with blowing up the container and rebuilding using the latest image.

I have that automated with another docker container called Watchtower. It updated SyncThing on 11/2 so a day or two after I had created it.

You can recreate synology package dockers as normal dockers. With the docker cli, you can just export volumes as tar.gz, if you use them instead of bind mounts, thats a nice base to make independent images. I did that at some point with a gitlab in anticipation to upgrade to dsm7. Switched from muntashirakons container in the syno package to official gitlab packages. Exported all config and db volumes, checked if the paths in official are different, changed any paths in configfiles and then just launched the official container with those settings and database parts. But then never upgraded to dsm 7. Primarily because it looks more annoying than 6.

The dsm even has some container description exporter. It some how looks like yaml from docker inspect or kubectl describe feature but in that form not importable anywhere except dsm.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.