Crashplan Max Memory Via Docker on a Synology NAS

Crashplan MAX MEMORY via Docker on a Synology NAS


Update the /usr/local/crashplan/bin/run.conf with the maximum value you want your java heap to be allowed to use:


SRV_JAVA_OPTS=”-Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m -Xmx1024m -Dnetworkaddress.cache.ttl=300 -Dnetworkaddress.cache.negative.ttl=0 -Dc42.native.md5.enabled=false”


If you’re like me and you have an awesome Synology DiskStation (I have a 1515+), you probably want to back up the all important data that you are storing.  Whether it is family photos or business documents, you typically will want to have an offsite backup in the event of a catastrophic disk failure or some other disaster such as a flood or fire.  Scott Hanselman has an excellent blog post outlining why you should backup your data as well as how thorough you should be about it.  Make no mistake, people think backups and redundant backups are a waste of time and money until they actually need them.  Please take a moment and read Scott’s excellent post.  Even though it is several years old, every point he makes is very relevant in today’s world.

Another quick tidbit that most people overlook is that Dropbox, iCloud, OneDrive, or Google Drive usually isn’t an adequate backup for working data.  In most cases, cloud providers will give you access to the most recent version of a synchronized file.  This means that if you accidentally save your thesis paper after fat fingering select all + delete, you’re in trouble.  Or, perhaps, you hit delete on the wrong file without realizing it.  While cloud providers are great and provide an excellent service of synchronizing data and files between devices, they don’t usually provide a good disaster recovery scenario when trying to retrieve old data that was overwritten or accidentally deleted.

I highly recommend Crashplan for all of your personal and small business disaster recovery needs.  Their pricing is incredibly great for their service (unlimited storage??).  Other comparable services are much more expensive.

Now that you’ve decided that Crashplan is the best thing since sliced bread, you’ll want to install it on your Synology NAS in order to backup your centralized data.  This can be a little daunting as Crashplan still hasn’t issued an official package for Synology NAS devices.

Previously, in order to get this working, you had to add an unofficial package source and install a package that worked around Crashplan’s install limitations.  Again, our friend Scott Hansleman has an excellent post about how to do this.  Unfortunately, Crashplan has a tendency to automatically upgrade itself and the update process doesn’t play nice with Synology DSM’s version of Linux.  This resulted in a lot of pain every few months when Crashplan autoupdated.  You really wouldn’t realize there was an issue unless you happened to check your backup statuses or had the Crashplan service email you fairly often if no backup was received.  Chris Nelson’s article details what was involved.

As with all things, eventually Crashplan’s update resulted in an update which wasn’t easily repaired.  Enter Docker!  Now we can run a version of Linux that is supported by Crashplan in a container, thus allowing updates to install properly.  If you want to go down this road, here are the directions to do so.  Thanks Mike!

A small caveat here, I did have to modify how my volumes were being attached to the container.  As some others stated, I had to manually add them via the DSM UI.  Attaching them via the command line did not work as expected for me.  Also, I needed to adjust some pathing so that I could adopt my previous Crashplan backup without sending all of my data to the servers again.

After all of this work, we now have a working backup solution that will backup our data periodically, storing versions and diffs so that you can retrieve older versions of your files if necessary.  Huzzah!  But wait…something’s wrong!  Crashplan keeps…well…crashing!

If you find something like this in the logs:

You may be backing up so much data that the Crashplan engine needs more memory in order to continue functioning.  That doesn’t make sense, you say.  I’ve got lots of memory in my Synology.  I even upgraded my memory to 16 GB like this guy did!

Here’s the big gotcha…you have to configure Crashplan to specify it’s max Java heap size in one of its configuration files.  Crashplan support has a decent article explaining why you need to do so.  Yes, you can do it through the GUI like the article mentioned.  Ultimately, you end up modifying the run.conf file.  I changed mine to allow Crashplan to use up to 8GB of memory if it needed to do so.


I had an issue in which my run.conf file was being reset to default.  I’m not exactly certain why this was happening, but it could have been due to a bad upgrade scenario.  Every time the container was restarted (due to a power event, DSM version upgrade, or something similar), the max memory was reset back to 1024.  I noticed in the logs that Crashplan was upgrading and restarting itself each time the container was restarted, so I’m guessing that was the root cause of the issue.  After spending some time trying to track it down, I simply downloaded the latest version of the docker image, launched a new container using the DSM UI, set it up exactly the same as my original container (mapping the exact same ports and volumes), copied the .identity and .ui_info files from the original container into the /var/lib/crashplan folder, and modified the run.conf to set the max memory size to 8GB (8192m).  After that, I simply restarted the container and the memory setting was respected between restarts.  I did have to log into my account again when connecting with the GUI running on my macbook pro to see if the backups were processing properly.

Finally, though, I have an install of Crashplan that should work properly with upgrades and will not crash when backing up my large data repository.


DotNetNuke and ApiExplorer

Exposing Web API endpoints from DotNetNuke is very easy to do and is extremely useful for accessing the internals of DNN. For example, if I want to get a list of all of the custom roles that are available for a particular DNN site, I can easily do so by creating a custom endpoint as illustrated at

There are a myriad of reasons you may want to create your own Web API endpoint within a custom DNN module, such as:

  • Exposing data to 3rd party systems
  • Accessing content from a companion mobile app
  • Automating tasks within your DNN site
  • Synchronizing data between DNN and an external system
  • Allowing different DNN modules to interact
  • Allow javascript on a module’s views to save and retrieve custom data

On a project I was working on, there was a need to expose an administrative api for a set of modules that were being developed.  As part of this effort, we wanted the api to be easily documented.  Luckily, DNN 8 now supports MVC modules, so it was a cinch to get started creating a new DNN MVC module project and then installing the Microsoft ASP.NET Web API Help Page package

Note: If you don’t have a Visual Studio project template for a DNN MVC Module for Visual Studio, you can find one here  The one used in this example is a simplified and modified version of Chris Hammond’s template.

If you compile at this point and get an error such as

CS0656 – Missing compiler required member ‘Microsoft.CSharp.RuntimeBinder.CSharpArgumentInfo.Create’

you will need to add a reference to Microsoft.CSharp.dll.

Web API Help Page Area


Now, let’s take a look at what happened when you installed Microsoft’s Web API help page package.  The first thing you’ll notice is that the package creates an Areas folder and stuffs all of its content within a custom Area.  While this is useful when building a normal MVC or Web API project, it causes problems with DNN since DNN does not support Areas due to its custom routing.  To fix this, we simply need to perform the following steps:

Move files and folders to the root of the module project

1) Move the /Areas/HelpPage/Controllers/HelpController.cs to the /Controllers/DnnApiHelpPageController.cs

The HelpController needs to be renamed to the controller name specified in the DNN manifest file.  In the case of this example, it is the DnnApiHelpPageController.cs file.

As part of this, the class name needs to be updated in code and the class needs to inherit from DnnController.  If you choose to use a different name, make sure you update the controller name in the DNN manifest file.

You may also want to update the namespace to correspond to the new location, but that’s not technically needed.

2) Move the /Areas/HelpPage/Views/HelpPage folder to the /Views/DnnApiHelpPage folder

As with all MVC controllers, the controller we moved above needs to have its corresponding views placed in the proper project folders.  Move all of the Views in the /Areas/HelpPage/Views folder to the /Views folder.  In order to make it easier, I renamed the existing Views/DnnApiHelpPage folder to a temporary name, copied the /Areas/HelpPage/Views/HelpPage folder to the /Views folder, and then renamed it to DnnApiHelpPage.

3) Delete the Areas/HelpPage/Controllers and Areas/HelpPage/Views folders

You shouldn’t need these folders anymore and they can safely be deleted.  You can verify that your views folder structure is correct by looking at the DnnApiHelpPageController.cs file in Visual Studio and confirming that calls to View() do not have a compilation error indicating a missing view.  The exception to this is the calls to  View(ErrorViewName);  since a view was not packaged as part of the nuget package.  You could easily create your own view for the error page, however.

4) Move all of the remaining files and folders to the root of the project except App_Start

The App_Start folder contains a configuration file that is normally called on the start of the web application.  Since we don’t have access to the web start event, we will handle this differently.  This is address later in this post when discussing a custom IApiExplorer implementation.

Solution after moving files and folders to rootQuick Summary

At this point, all of the files should be moved over to the root of the project with the exception of the HelpPageConfig.cs file in the Areas/HelpPage/App_Start folder.  I recommend going through renaming all of the namespaces so that there is no confusion, but this should be an optional step.  If you were to add an instance of this module to a page on your DNN site, it should function and enumerate all of the exposed apis.

Default API Explorer with DNN apis
Default API Explorer with DNN apis

Side Note

If you were to build and deploy the module to your DNN installation at this point, you might have a failure due to not being able to load System.Web.Mvc.dll.  This is because DNN is using an older version of the System.Web.Mvc.dll ( and the help page package references 5.2.3.  You can attempt to downgrade the version of System.Web.Mvc.dll by specifying the version of the package you want PM> Update-Package Microsoft.AspNet.Mvc -Version 5.1.0 .  Be aware that this will reinstall the help page nuget package and you may need to delete files/folders in the Areas/HelpPage folder again.  Another way to fix this issue is updating the binding redirect in the DNN sites web.config to

Additionally, you may get a similar error complaining about System.Net.Http.  You may need to modify your web.config for the DNN site in two places.  Adding another binding redirect as follows:

And adding an entry in the compilation section of the web.config

Fixing OTHER Issues

1) Fix Url.Action call in ApiGroup.cshtml

Right now, if you click on a link to drill into the details of an api, you will get an exception indicating that Default.aspx was not found or does not implement IController.  Obviously, this error message is not exactly accurate.

Error clicking api details

Because we moved/renamed the controller, we also need to update the call to  @Url.Action() in the /Views/DnnApiHelpPage/DisplayTemplates/ApiGroup.cshtml view.  The correct line of code should change the second parameter to the name of the controller.  In this case, it is “DnnApiHelpPage” instead of “Help”

2) Update the @model directive on CSHTML pages

DNN handles MVC pages slightly different.  You need to setup the views so that DNN can process them appropriately.

If you look at the Api.cshtml file, you’ll see several issues which are quite straight forward to fix.  First, you should add the following:

The above uses the DnnWebViewPage<> as its base class for the view.  In addition, the generic type parameter indicates the type of the model passed to the view (the @model directive is no longer needed at this point).  Next, we use the ClientResourceManager.RegisterStyleSheet to register the appropriate stylesheet.  Lastly, the  @using DotNetNuke.Web.Mvc.Helpers statement needs to be added since DNN supplies its own helper functions, @Html.DisplayFor() for example.

Note: In my environment, the IDE complained about the System.Net.Http.dll not being referenced even though it was.  After setting Copy Local to true on the reference, the IDE was happy again.

Similar updates should be applied to all of the views in the DisplayTemplates folder, as well as Index.cshtml and ResourceModel.cshtml.  Since there are quite a few, please see the attached project for reference.

3) Exception when you have multiple models with the same name

In many cases, you will have the same model name in different namespaces.  This will cause the help page generation to fail due to duplicate types detected.  This is because the help page generation uses the type name instead of the full type name.  There is a simple fix for this which is explained here

In a nutshell, in the ModelNameHelper.cs file, update two lines of code to get the type’s full name.

Also, to make sure everything is complete, do the same in the HelpPageSampleGenerator.WriteSampleObjectUsingFormatter method:

At this point, you will have a fully functioning api browser that is always up to date since it examines the loaded assemblies to determine what endpoints are exposed.

Api endpoint details

There are a few strange issue in how the standard ApiExplore  object works with DNN.  I will explore these in a future blog post.

  1. DNN lists all actions for all routes: I’ve worked around this by subclassing ApiExplorer  and creating my own filter in the ShouldExploreController  method.
  2. DNN displays the route incorrectly: If you look at the screenshot above, you’ll see that the URL for the endpoint is listed incorrectly.  DNN displays the full name of the controller type in the URL instead of just the controller name.  To fix this, I added code in my custom ApiExplorer  constructor that will modify the RelativePath  property of each ApiDescription  object in ApiExplorer.ApiDescriptions .




Xamarin and Xamarin Forms Sample Projects

Xamarin is an awesome company.  I’ve been a fan of the mono project for a decade now and I’ve used it professionally at several large companies.  I was slightly worried when Novell was bought and the future of the mono project seemed dim, but I should have had faith in Miguel and the others as they quickly formed a new independent company and started moving forward at lightning speed.

Up until recently, I haven’t had the opportunity to work on a professional mobile project using the Xamarin Platform, so when the when one presented itself, I jumped at the chance.

The requirements of the project were straight forward so I decided to use Xamarin Forms to share as much code between Android and iOS as possible.  Overall, Xamarin Forms is quite impressive, as it allows you to share a lions share of your UI code without compromising the native feel of the application.  As with any relatively young framework, I’ve had to work through small issues.  One of them was the absence of the Cancel button on an ActionSheet for iOS.  Several people had reported this to be a problem based on my searches in the forum and I proceeded to clone the xamarin-forms-samples to check it out.

As I was working through some issues, I came across an issue in which Xamarin Studio was failing to compile and deploy to the iOS Simulator.  It failed with an error of ‘No valid iOS code signing keys found in keychain’.  After a little bit of google-fu, I found a bug with a similar symptom.  Also, this post on the forums Error: No valid iPhone code signing keys found in keychain. when I update xamarin 5.7 HELP ME!!!! illustrates and contains the work around for the problem.

Happily, when I removed the Custom Entitlements from the iOS Bundle Signing properties in Project Options, the sample ran fine in the simulator.