Duplicati failing to see content - [SOLVED]

I'm finding now that my luck has run out as Crashplan is no longer honoring their little free 1 year license cards they used to give out. I was using these, and have about 5 yrs worth of cards left. But alas the site is now gone, and sending a note to support indicated they are no longer honoring those cards. Based on this info and the cost comparison between Crashplan and Amazon Cloud Drive - I've decided it's time to move over to ACD. Not to mention I trust the infrastructure much better since Crashplan basically uses CoLo's.

Anyhow, problem I've found is I can't see the content in my data folders with the Duplicati plugin. Duplicati seems to be the answer I need to get the system backed up securely to Amazon Cloud Drive. When I start up the Duplicati interface, I can browse to the top level folders, but after that I can't see the subfolders and content within. Is there a way to alter the permissions or the user that the Duplicati plugin runs at? In this case, based on some of the content needing to be backed up, I'd like to be able to run this as root. I know not always recommended, but I want to be backing up some system files (like OMV backups) as well. Running as root with alleviate this issue as permissions can be a hassle due to all the different data types being used.

PS - This is speculative as I have no idea what permission level the Duplicati service is running, but I'm guessing based on what I see that it's not running as root.

Zitat von ryecoaaron

The service does run as root. On my test VM, I can even see files in /root/. Not sure why you can't see some files.

You are correct! Sorry, it turns out I was being foolish. When I was doing the first browse, it seems duplicate hadn't finished crawling the system, so it was only showing me a blank top level folder. I came back to it now recently and noticed all the subfolders and content starting to show. The second issue I found, and I'm going to call this out for others as it's easy to overlook, I didn't alter the FILTER section. Apparently the default filter was set for Exclude *. So essentially it was making a nice backup of the folder structure it seems and thats about it. LoL. Now that I flipped that to an Include *, everything seems to be tracking and it's busy chugging along to count up all the files and start the upload.

On a side note - anyone have some basic raw stats to share of how much they're backing up? Just curious if we've found a choke point yet where I may need to break this down into backup sets due to the massive amount of content being protected.

@ryecoaaron - just wanted to revive this to ask one thing - as you mentioned it requires mono. In my case, I did not enable the mono or mono testing repos. I believe these are if I wanted to install mono directly and use it for other purposes. But knowing that Duplicati uses it, is there somewhere that I can edit or alter configs for the mono that is installed?

The reason I ask, is that I am constantly running into the Certificate not trusted errors with Duplicati. The reason is that the plugin is trying to connect to the Amazon API servers and receiving a certificate root that is for some reason or another trusted in the Mono cert chain. It has been suggested in other places, to avoid this, to simply run a command to allow an update to the trusted roots which can grab the roots being used by Amazon for my cloudDrive target in Duplicati.

Any idea how one can achieve this? I think I even saw a GitHub issue listed with the same issue that you had commented on, but you had done like many and accepted the one-off hash. Unfortunately this problem continues to creep up and likely will due to the sheer number of Amazon front end systems we may encounter and their rotation, we need to be able to get the Chain into trust by getting the higher root in.

Zitat von ryecoaaron

I just updated the plugin to run the mozroots command to download/update the certs. Maybe that will fix it.

Aha, ok so it seems then perhaps you have solved the issue I'm running into. Kept having the cert error show up with untrusted cert chain. If you've got it to use the mozroots now, I think that should resolve the issue.

I'll try to keep an eye on it now that I've updated. Thanks for being on top of these plugins, you are the man!

Zitat von cds

The current workaround is to set the following environment variable:
MONO_TLS_PROVIDER=legacy

I was just coming in to make a comment about this not solving the issue for me either. I'm happy to hear there is a workaround. Forgive my ignorance, but where would I be inputting this environment variable? Is this something I need to login to the console? Or am I able to set this somewhere in the OMV GUI?

EDIT: I did google OMV environment variables, but I found some QUITE outdated information in a Wiki from 2014 about version 0.4 and 0.5. Want to have myself validated before I try making changes as outlined there. And has this been tried/tested to work? All the env var I see start with OMV, and after googling the provided solution, I find Mono issues across the board using this vs OMV specifically.

Touche @ryecoaaron - I over read that and didn't pick up the Maybe. My fault. I thought it included that and was planned to fix it. Either way, I was hopeful. I'd like to give the suggestion from @cds a go, but I'm not 100% on it being used in OMV vs regular debian based install. I don't want to hose my system in it's current state for the sake of possibly fixing, until I know it fixed OMV specifically. I'm almost done with a 2TB backup, so I'd like to at least hope it finishes before I interrupt it ... again.

Alright, so I've got good/bad news to report.

Good - It worked!! Bad - I can't tell for sure which fix actually did the trick.

I went through and updated to the latest plugin version with the EnvVar entry. It didn't work at first. I decided especially being that it was an environment variable, it may need to reload something under the covers first. So I finally decided to shut down my docker host relying on this temporarily, to restart the OMV box. Upon restart, I validated Duplicati. This time it worked. So I can say one of those 2 things fixed it, but I can't target 1 or the other as the specific fix, as I didn't restart last time with the mozroots update which could have possibly fixed it. I guess for now it doesn't hurt to have both items in there. But more importantly, Duplicati isn't complaining about certs anymore!

Apparently, I spoke too soon. I'll keep an eye on it, but it crept up again. Went back to check on current status after successful test of connection, and saw the same error out message again. Requested a new token, and added in the first cert to the "accept" list manually. Going to start a separate thread for this though as this one is building, when obviously the original problem isn't correlated.