NAS firmware upgrade breaks mono (wrong mono version)


It is saying that it needs to a specific value from the library, but that value is not present. Since the library (System.Net.Security) is a core part of Mono, it suggests that the Mono version is broken (missing the field that should be there).

What version of Mono are you running?


Mono is definitely broken. I ran “mono /data/Duplicati/Duplicati,CommandLine.exe help” and got pages of errors about bit loading signatures and unhandled exceptions. Then I tried reinstalling mono using the instructions I had found earlier and I’m getting this:

 mono-devel : Depends: libmono-system-drawing4.0-cil (>= 3.0.6) but it is not going to be installed
              Depends: libmono-system-runtime4.0-cil (>= 2.10.1) but it is not going to be installed
              Depends: libmono-system-servicemodel4.0a-cil (>= 3.2.3) but it is not going to be installed
              Depends: libmono-system-web-services4.0-cil (>= 1.0) but it is not going to be installed
              Depends: libmono-cil-dev (= but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

As this is way outside my ability to fix, I think I’ll have to find another way of running Duplicati on my network. I’m not capable of handling something this complex every time they update the ReadyNAS software. What’s weird is that backup and restore both appear to be working, though I’m getting yellow warning boxes for every operation in the web GUI but there are no errors in the logs:

Warnings: []
Errors: []

I think I’ll look into moving my Duplicati installation to another system.

mono -V results in:

Mono JIT compiler version (tarball Fri Oct 13 23:01:19 UTC 2017)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors.
        TLS:           __thread
        SIGSEGV:       normal
        Notifications: epoll
        Architecture:  armel,vfp+fallback
        Disabled:      none
        Misc:          softdebug
        LLVM:          supported, not enabled.
        GC:            sgen (concurrent by default)


That looks like a problem with the package manager on your system. I have no hints for fixing it. Hope you got something working.


Thank you for your help. I have set up a new server and I am moving Duplicati to that machine. Installing Duplicati on a NetGear NAS is not a reliable platform because firmware updates tend to be unstable and break things. It’s a beautiful piece of hardware, but my goodness has it given me headaches. I am going back to using it strictly for storage and I’ll let the new server handle everything else.


I assume you have seen this?

If so, please feel welcome to reply to that how-to topic, explaining why you would not recommend installing duplicati on a ReadyNAS. That could save others from those headaches.

Personally, I am considering upgrading my ReadyNAS Ultra to OS6 (because mono doesn’t run on the old RAIDiator firmware) just ti be able to run duplicati. But it looks like it’s not worth the trouble?


In my experience the opposite is true. The OS (ReadyNAS OS6) is rock stable and well maintained. Updated recently to version 6.9.1.

BTRFS is the best filesystem for a NAS I can think of (love the shadowcopy feature). The ReadyNAS devices will auto-detect and auto-repair file system corruption (if a CRC check fails for a file, ReadyNAS will automatically restore the file from the last shadowcopy, which is from less than an hour ago, marks the blocks allocated by that file as non-usable and send you a notification by email about the recovery process). This makes ReadyNAS a rock solid device for storing important data.

I’m not a Linux guy, but managed to get Mono installed and created a small script to start Duplicati from a regular file share. Had some issues with reporting (SSL issues), but --accept-any-ssl-certificate solved this. Until now, I’ve had not a single problem using Duplicati on my ReadyNAS (5 backup jobs running daily, updated Duplicati and ReadyNAS OS multiple times).


You upgraded from 6.8.x to 6.9.x and your Duplicati or Mono didn’t break? That is interesting. I wonder what happened to mine.


Indeed. Backing up for almost a year on my ReadyNAS using Duplicati. The latest 6.8 OS version (V6.8.1) is from September 28, 2017. I guess I’ve updated Ready OS6 8 to 10 times from 6.6.x to 6.9.1. None of them did break Mono.


So in reply to @tophee as well, I actually used your guide to get things installed under 6.8 (I don’t recall which exact version; I’ve been running Duplicati on it since at least mid-2017). Thank you very much for putting that guide together, it was extremely helpful. It appears my experience was unique and I’ll chalk it up to bad luck.


Well, it’s fixed.

I edited one of the lines in the installation guide @kees-z wrote to:

echo "deb jessie main" | sudo tee /etc/apt/sources.list.d/mono-xamarin.list

(Changed “wheezy” to “jessie”)

Then apt-get update, followed by apt-get -y install mono-devel, followed by a really long list (and wait) while mono got set up again, and now Duplicati.CommandLine.exe help returns no errors followed by the help text.


Thanks for reporting this. ReadyNAS OS6 is a customized version of Debian 8 (Jessie), so my article seems to be incorrect about this. Changed it in the howto article.
I don’t know if this was a wrong Copy/Paste action, or that I actually installed the Debian 7 version.

Does anybody know how to verify which Mono version is installed on my ReadyNAS (Wheezy/Jessie)?


Your original instructions worked perfectly for me; I wouldn’t have known to make this change until I went back again and tried to update mono, and when I did apt-get update I noticed everything except the mono project said “jessie” so I figured I would try it. I’m glad I was able to help. Would it be worth noting in the guide to suggest people do a “lsb_release -a” on the NAS to check which version of Debian is installed and update the mono line accordingly? I don’t know how often that changes though.

Looks like:

apt list mono-devel

will give you the mono version and codename.


Thanks. Result for this command is on my ReadyNAS:
mono-devel/stable-jessie all [upgradable from:]


Here’s what I have (now):

root@NAS:~# apt list mono-devel
Listing... Done
mono-devel/stable-jessie,stable-jessie,now all [installed]
N: There is 1 additional version. Please use the '-a' switch to see it
root@NAS:~# apt list -a mono-devel
Listing... Done
mono-devel/stable-jessie,stable-jessie,now all [installed]
mono-devel/oldstable,oldstable 3.2.8+dfsg-10 all

I didn’t run the command before I upgraded; I’m learning as I go. I wonder if that 3.2.8 version is the Wheezy version, since I assume mono was never part of the ReadyNAS core installation.


This is what I get when using the same commands:

root@NAS:~# apt list mono-devel
Listing... Done
mono-devel/stable-jessie all [upgradable from:]
N: There are 3 additional versions. Please use the '-a' switch to see them.
root@NAS:~# apt list -a mono-devel
Listing... Done
mono-devel/stable-jessie all [upgradable from:]
mono-devel/stable all
mono-devel/now all [installed,upgradable to:]
mono-devel/oldstable 3.2.8+dfsg-10 all

Does this mean that you are using the latest Mono version ( and that I downloaded the latest version, but actually use an older version (
If this is true, is it recommended to update to I don’t have any problems with the current setup. If updating is recommended, how to do it? apt-get update && apt-get-upgrade?


Yes, the Debian repo’s still carry Mono version 3.x.

It looks like it. You can run mono --version to be sure.

In general I would say yes, but on the other hand “if it ain’t broke don’t fix it” :smiley:

Yes, that sounds correct.


I’ve finally upgraded Mono to
apt-get update / apt-get upgrade did not work, because the OS was complaining about public keys that could not be found. This must have been the reason that version 5 was downloaded, but never installed.

I’ve removed mono with apt-get remove mono-devel and apt-get remove --purge libmono*. Then I reinstalled mono with the commands described here (for Debian 8).

Everything seems to work fine, Mono is installed and active. I was hoping that this would resolve another issue: email and http reporting doesn’t work, unless I supply --accept-any-ssl-certificate. This isn’t fixed with the fresh Mono installation.
After some digging, I found out that I have exactly this problem:

With the difference that backups (including reporting) work for me when I supply --accept-any-ssl-certificate.
Any suggestion how to get everything to work without the need to use accept-any-ssl-certificate?


You should be able to get it working simply by running cert-sync:

Help with oauth failure

Problem solved! But I have no clue why…
Tried the cert-sync command multiple times, always with the same result:

....@....:~# sudo cert-sync /etc/ssl/certs/ca-certificates.crt

Mono Certificate Store Sync - version
Populate Mono certificate store from a concatenated list of certificates.
Copyright 2002, 2003 Motus Technologies. Copyright 2004-2008 Novell. BSD licensed.

Importing into legacy system store:
I already trust 176, your new list has 174
Import process completed.

Importing into BTLS system store:
I already trust 175, your new list has 174
Certificate added: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Certification Authority
1 new root certificates were added to your trust store.
Import process completed.

But I still got errors without using --accept-any-ssl-certificate=true. Magically, it now works without this setting!


Ummm, yay? :wink: