Updated Docker Package 20.10.3 available

Currently reading
Updated Docker Package 20.10.3 available

Will this update remove the deprecated DDSM? Because if that’s the case I will hold off the update for now :(
several updates before already killed ddsm. But this one will require a specific DSM version as well, so the combination of 2 will kill it for sure.
 
Ok so I can get rid of my VMM Ubuntu boxes running the newest Docker version.
But it would still be an older version, because the latest Docker version is 20.10.7

This is a distinct opportunity for Synology to finally equalize the docker version, but unfortunately they don't do it again. They clearly choose to be a few version behind after all. And that will probably only get more so if they don't increase the frequency of updates for the Docker package.

For the time being, I'll stay on my VMM Debian Docker. Also since I am still suffering from the kernel bug. For me Docker on VMM Debian works fine, everything runs like clockwork.
 
The update somehow failed. Would have been nicer if it was automated than the manual update. Just a quick question here... Do I need to stop all the images first and then update?
 
Last edited:
I upgraded "on the fly" and everything kept working. YMMV though.
-- post merged: --

But it would still be an older version, because the latest Docker version is 20.10.7

Tried to upgrade to 20.10.7 by installing the latest binaries (after removing the Docker package), but unfortunately there is still the same error message as before (when upgrading from Docker version 18.09.8). It does work for --storage-driver vfs but for btrfs still no luck. Apparently there is still an issue with btrfs-progs? I would have thought this would be not a problem when the Docker major version is the same. And keep up with recent Docker releases but that is not going to happen. 🙁
Code:
$ docker --version
Docker version 20.10.7, build f0df350
$ docker run hello-world
ERRO[2021-06-03T09:23:07.666225382+02:00] Handler for POST /v1.41/containers/create returned error: Failed to create btrfs snapshot: inappropriate ioctl for device
docker: Error response from daemon: Failed to create btrfs snapshot: inappropriate ioctl for device.
See 'docker run --help'.
$
 
docker: Error response from daemon: Failed to create btrfs snapshot: inappropriate ioctl for device.
Did you try to update the containerd binaries as well? Syno's 20.10.3 commes with 1.4.3, while (at least on ubuntu) 20.10.7 commes with 1.4.6.

Just replacing the Docker binary, might not be enough: Docker itself is a comfort wrapper that delegates image and container filesystem and container lifecycle handling to containerd, while implementing the networkwork magic. containerd itself is a comfort wrapper that delages handling of the container lifecycle to runc.

But maybe Synology "just" customized btrfs to break api compatibility that containerd requries.
What Synology does to the docker engine (and many other packages) realy is a crime...
 
Last edited:
Did you try to update the containerd binaries as well? Syno's 20.10.3 commes with 1.4.3, while (at least on ubuntu) 20.10.7 commes with 1.4.6.
Yes, what I did it is remove the Synology Docker package completely and after that install the static binaries as described here. Basically his works. But not with the btrfs storage driver...

I tried different storage drivers aufs, overlay2, btrfs and vfs with various results. Storage driver vfs does seem to work on a btrfs file system as well, but of course you do not have the benefits of btrfs since vfs is not a union file system and there is no cow support.

I did write some of it down here...

But maybe Synology "just" customized btrfs to break api compatibility that containerd requries.
Probably. 🙁

Maybe I'll see if I can figure out what the differences are when compared to a Ubuntu install...
But to be honest, I'd rather not tinker with the btrfs file system and risk breaking it all (although I always test this first on VirtualDSM).
It would have been nice to just install Docker myself and use the btrfs strorage driver without having to go through all of this...

More info about the btrfs storage driver failing here.

Edit:
If I replace all docker binaries in /volume1/@appstore/Docker/usr/bin with the 20.10.7 ones, I get the inappropriate ioctl for device error message.

(in /var/packages/Docker/etc/dockerd.json, I also needed to replace the custom log-driver from db to json-file but that is another story...)

If I restore the dockerd version to the one from Synology everything seems to be working again. So it looks like Synology made some changes to make it work. The only question is: what did they change?

Note to self: next steps here and here?

Code:
$ docker version
Client:
 Version:           20.10.7
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        f0df350
 Built:             Wed Jun  2 11:51:04 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server:
 Engine:
  Version:          20.10.3
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.15.6
  Git commit:       a3bc36f
  Built:            Mon May 10 03:59:47 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.4.6
  GitCommit:        d71fcd7d8303cbf684402823e425e9dd2e99285d
 runc:
  Version:          1.0.0-rc95
  GitCommit:        b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
$
 
But it would still be an older version, because the latest Docker version is 20.10.7

I know. I was just joking/being sarcastic. :)

For the time being, I'll stay on my VMM Debian Docker. Also since I am still suffering from the kernel bug. For me Docker on VMM Debian works fine, everything runs like clockwork.
Same here (although I have Ubuntu instead of Debian). It also have a security advantage, as I run NGINX Proxy manager on the seperate VM and that received the traffic from the outside world.
 
I did write some of it down here...
Nice deep dive into the Synolog Docker RCA universe :)

A long time ago I tried to compile the binaries using Synology's build chain and kernel headers, though since the build process bootstraps build containers, the Synology build chain and kernel headers actualy never made it into the build and just generated the same set of generic binaries that you downloaded - maybe with different commit id's and build dates, but appart from that identical. I have been on that track two years ago and then gave up on it.
 
I did some further research.

If I replace all the Synology docker binaries in /volume1/@appstore/Docker/usr/bin (version 20.10.3 from the latest Synology package) with the 20.10.7 ones, I get the inappropriate ioctl for device error message.

(in /var/packages/Docker/etc/dockerd.json, I also needed to replace the custom log-driver from db to json-file but that is another story...)

If I restore the dockerd binary (version 20.10.7) to the one from Synology (version 20.10.3) everything seems to be working again. So it looks like Synology made some changes to the dockerd source code to make it work?

I think the error message inappropriate ioctl for device error originates from this location.

I do know how to compile the dockerd source code. The question is: where do I find the changes that were made by Synology? I do know there is some source code available on SourceForge, but I could not find anything related.

Ideas anyone?
 
Yep, their patch provide the required compatibility. Replacing the binaries /var/packages/Docker/target/usr/bin/docker
and /var/packages/Docker/target/usr/bin/dockerd with the downloaded 20.10.3 binaries, setting log-driver from db tojson-file in /var/packages/Docker/etc/dockerd.json at least allows the package to start normaly, though it is impossible to start previously existing containers. It seems only new containers can be created. As I don't use btrfs, can't realy tell the effects on that.

Had to laugh hard about this warning in generic 20.10.3:
WARNING: the aufs storage-driver is deprecated, and will be removed in a future release.
 
@one-eyed-king
Yes, but where can I find that patch?

The docker/engine is licensed under the Apache License 2.0 so to be honest I don't have too much faith in it... 🙁

A permissive license whose main conditions require preservation of copyright and license notices. Contributors provide an express grant of patent rights. Licensed works, modifications, and larger works may be distributed under different terms and without source code.
 
Would you recommend upgrading the Docker version to the latest one? I think its version 20.10.3-0552 for DSM 6.2.x

I dont think I'll upgrade to DSM 7 just yet, but was thinking of upgrading Docker to the latest one. Any concerns?
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

For the heck of it, I just checked again in docker container, and it announced an update was available. I...
Replies
4
Views
485
  • Question
Do realize, that enabling any user to run docker containers is largely the same as giving that user full...
Replies
6
Views
1,082
Hello, I already have it configured perfectly with wireguard. I was looking at the Gluetun configuration...
Replies
4
Views
764
Thanks... I tried something similar with rsync. The docker volume lived in...
Replies
7
Views
768
I can’t find any option to restore just the settings. 1710356648 Phew, managed to fix it. Within the...
Replies
4
Views
583
Good to hear. Deluge has not been updated for almost two years now as an app, nevertheless. But it gives...
Replies
12
Views
1,275
  • Question
Open an issue on that GitHub page. The developers will be glad to assist. OP has posted two threads on...
Replies
5
Views
1,238

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top