Before I do something I’ll regret - do you know how the container update process works? I’ve set my unRAID box to check for Docker updates Daily with a time 5 min. in the future and it’s not finding an update for Duplicati.
I could manually re-install, but I was hoping the container updater would take care of things for me…
I don’t run Duplicati in a container currently, but I’d have the container configured with it’s databases mounted to either a persistent volume or just straight out to the host disk. Then just destroy the container and deploy the new image to update. The new container will upgrade the databases on startup.
Agreed - that’s how is should work, but I’m trying to avoid it for two reasons.
I’m still not sure I’ve got my container configured correctly so may lose all my configs (but that’s OK - I’ve exported everything just in case)
I get linuxserver Duplicati container updates fairly frequently - I’ve NEVER gotten an official Duplicati container update.
I always assumed the lack of updates was because the container was the beta only, but even with 188.8.131.52 beta I didn’t get a container update. So I suspect there may be an issue with how we’re hosting or updating the container that isn’t advertising the fact. (Though again, that could just be me using containers incorrectly.)
I vaguely recall LinuxServer stating somewhere they have a policy about canary releases. Maybe. My guess is they only update to the version on the website (beta 184.108.40.206) and every other release they do is just OS updates.
Wow - seeing my typos quoted by somebody else is almost as bad as hearing my own voice being played back.
I don’t disagree with your view of LinuxServer probably being only beta and most of the updates I see being OS related. However, that doesn’t explain why I don’t recall ever seeing an official container update.
Assuming the https://hub.docker.com/r/duplicati/duplicati/tags/ page reflects an “update” to the container, I should have seen 18 updates coming in. I just checked my update notification emails from my unRAID box and I’ve gotten 0 about the official Duplicati container.
Anyway - since no update was “detected” by unRAID I used it’s “Force update” feature to update the docker. As expected, it has reverted to version 220.127.116.11 beta of Duplicati - but I’m not sure which one as it won’t start due to a The database has version 6 but the largest supported version is 4. error. D’Oh!
So at this point I would recommend @kenkendk’s manual fix over updating the docker container if you are currently running anything NEWER than 18.104.22.168 (which I think is the last one with database version 4) understanding how to use Docker tags to make sure you’re using at least base container version 22.214.171.124.
Note that forcing the container update (resulting in 126.96.36.199. beta) then using the Duplicati updater to get to 188.8.131.52 experimental did NOT bring in the the missing Microsoft providers.
I’m sure I’m doing something wrong or we’d be hearing more complaints from Docker users.
On my unRAID box re-installing with defaults as well as removing the container and installing from scratch did NOT bring back the missing Microsoft providers (even after using the Duplicati updater to go from 184.108.40.206 beta to 220.127.116.11 experimental). Again, this could be 100% my configuration issues so if somebody else can confirm whether or not the updated container is working for them that would be great!
The issue I was having with my official Docker container on unRAID is that I’m a Docker newbie and didn’t realize I needed to set my Repository to “duplicati/duplicati:experimental”.
Using the default of “duplicati/duplicati” just pulled the most recent stable version (hence 18.104.22.168 beta). Even though I updated Duplicati to 22.214.171.124, the Docker OS was still based on the 126.96.36.199 image so it did NOT include the missing DLLs.
When I changed my Repositor to “duplicati/duplicati:experimental” it updated my Docker container (without losing anything) and now that it’s based on the 188.8.131.52 container it DOES show the OneDrive v2 options!
So basically, everything I said above on this thread can be ignored because I was using the Docker images incorrectly.
As for @ts678’s issue, it sounds like he had been doing things the RIGHT way (using the :linux-amd64-184.108.40.206_experimental_2018-11-08 tag) and still ran into missing OneDrive v2 destinations.
My guess is that this might have been be due to the 220.127.116.11 container OS still missing the dlls and if he had used 'duplicati/dupliacti:experimental` OR updated his docker container without the manual fix then it would haev worked for him.
But hey - I got to learn something new and he verified kenkend’s manual fix works.
I started using Docker two days ago, so I didn’t know about automatic updates or notifications. I did see that getting a specific image needed a tag. That worked well for the “duplicati” images. Still haven’t found how to achieve the same thing for “linuxserver” in terms of knowing what Duplicati version a given tag will provide…
Can you provide any good links on the Docker update scheme? I’m finding ones that sound like an “update” means wiping out the application data the old one had (and the reply to that is often “don’t store app data”). Basically, an update sounds like a fresh install, although I do see some tools attempting to help the problem.
My post on 18.104.22.168 failing was 9 hours before 22.214.171.124 existed (thanks to @kenkendk for the amazing work), so yes it was missing dlls. I gave comment on updating earlier. But what of @JonMikelV Windows 10 issue, and it’s also not clear whether the opening post from @arktex54 was Windows, Docker, or something else. While I’m thrilled about the Docker fix, it’d be good to know that Windows is working (though it works for me).
Linuxserver are not super transparent about the images. They do increments every time they update anything in the image (e.g. OS packages). I downloaded the image and manually checked the version of the commandline tool. It’s 126.96.36.199. It usually works well since they just get the latest stable software. Sadly we don’t have stable software yet
In essence when updating docker you just throw away your container and make a new one. What’s important is to “persist” the data that matters between containers. In our case you want to persist your Duplicati database.
Persistence can be done with docker volumes. I like to go a slightly different way using bind mounts. I find them more tangible because they exist outside the container so you can see and interact with it.
I’m guessing my Windows 10 issue goes back to the “base” vs. “current” version design.
When I ran BackendTool.exe help it was in the INSTALL for, not the update folder. I think there’s a pre-existing issue with those tools not looking in updates folder for a newer version.
I’ll try to test that later tonight.
As for Docker stuff, I’m strictly a consumer so far. The container updates DO fully replace the existing container which is why it’s so important to get your container mappings correct.
Basically, there are certain paths (such as /backups, /data, and /source) that Duplicati will look to use. By default, those paths are INTERNAL to the container so anything written there will be lost during a container update.
But you can map those internal paths to EXTERNAL footers l folders on the device running the container. That way stuff saved to those files is store outside the container won’t be lost during a container update.
Edit: looks like Pectojin beat me to the punch. I agree on mount points / mapping vs volumes.
188.8.131.52 base started 184.108.40.206, and the code isn’t recently added. Process Monitor showed it like this:
6:02:23.1838051 PM duplicati.commandline.backendtool.exe 8144 Process Start SUCCESS Parent PID: 8972, Command line: "C:\ProgramData\Duplicati\updates\220.127.116.11\duplicati.commandline.backendtool" help, Current directory: C:\Program Files\Duplicati 2\,
Regardless, I hope there’s a nicer explanation for your result than there being another bug to find.
Back to Docker, it sounds like my test of just using a new container should be equivalent to an update regarding whether or not backends are found, and I probably won’t set up any more realistic test now, however I’d welcome test reports from anyone who’s already set up in a way that allows upgrades, i.e.:
Ditto. I’m also looking for testers of manual fix or new image at GitHub # 3198 I updated about this.