No files listed when selecting "Manage Files"

[ReallyFarFromHome]

Running the latest 2.14.0 and noticed that when I clicked on Manage Files to add/remove files/folders to the backup set, only two folders are displayed, when there were dozens of folders that were selected to be backed up. When I try to Restore Files, it looks like there is nothing to restore until I get to 4/24, which was the date I believe I updated to the newest version. So, it looks like the files exist both physically in my NAS folders as well as on the Crashplan destination site, but not in the Crashplan docker app. No settings had been changed at all, just a simple upgrade. Am I missing something? CP seems to think there are no folders to backup.

[septeven]

Hi, any news on this ?

I am experiencing the exact same thing. I have updated my docker image from 7.7.0 to 10.0.0 on June 20th (I am using the docker image on my Synology NAS, which is now under DSM 7.1)

When I open Crashplan docker interface, and:

• go to Manage Files, I can see my selected folders to backup, but when I click on those folders, they are empty.
• go to Restore Files -> No files nor folders here anymore. I have to select the date before the day I updated Crashplan to see the usually backup folders OR I have to select the 'Include deleted files' option under the three-dots menu.

It looks like all my folders that I've backup since ~6 years this way are now considered as deleted files for Crashplan, and this is terrifying me actually ...

Would you please help me on this, this is the first time I am experiencing such a thing with the CrashPlan docker image.

Thank you

[jlesage]

Can you share the config of the container ? Looks like a permission issue, where CrashPlan has no read permissions on the files.

[septeven]

Sure, would you mind just letting me know how to share it (screenshot ? command to type?) ? Sorry about that.

[septeven]

OK maybe this ?

   "CapAdd" : null,
   "CapDrop" : null,
   "cmd" : "/init",
   "cpu_priority" : 50,
   "enable_publish_all_ports" : false,
   "enable_restart_policy" : true,
   "enable_service_portal" : null,
   "enabled" : true,
   "env_variables" : [
      {
         "key" : "PATH",
         "value" : "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
      },
      {
         "key" : "LANG",
         "value" : "en_US.UTF-8"
      },
      {
         "key" : "S6_BEHAVIOUR_IF_STAGE2_FAILS",
         "value" : "3"
      },
      {
         "key" : "S6_SERVICE_DEPS",
         "value" : "1"
      },
      {
         "key" : "USER_ID",
         "value" : "0"
      },
      {
         "key" : "GROUP_ID",
         "value" : "0"
      },
      {
         "key" : "APP_NAME",
         "value" : "CrashPlan for Small Business"
      },
      {
         "key" : "APP_USER",
         "value" : "app"
      },
      {
         "key" : "XDG_DATA_HOME",
         "value" : "/config/xdg/data"
      },
      {
         "key" : "XDG_CONFIG_HOME",
         "value" : "/config/xdg/config"
      },
      {
         "key" : "XDG_CACHE_HOME",
         "value" : "/config/xdg/cache"
      },
      {
         "key" : "XDG_RUNTIME_DIR",
         "value" : "/tmp/run/user/app"
      },
      {
         "key" : "DISPLAY",
         "value" : ":0"
      },
      {
         "key" : "DISPLAY_WIDTH",
         "value" : "1280"
      },
      {
         "key" : "DISPLAY_HEIGHT",
         "value" : "768"
      },
      {
         "key" : "S6_WAIT_FOR_SERVICE_MAXTIME",
         "value" : "10000"
      },
      {
         "key" : "KEEP_APP_RUNNING",
         "value" : "1"
      },
      {
         "key" : "CRASHPLAN_SRV_MAX_MEM",
         "value" : "1600M"
      }
   ],
   "exporting" : false,
   "id" : "691dadc13147e34ad400995d92e6d92da361927857fd6237cd034b4bff34e19f",
   "image" : "jlesage/crashplan-pro",
   "is_ddsm" : false,
   "is_package" : false,
   "links" : [],
   "memory_limit" : 0,
   "name" : "crashplan-pro",
   "network" : [
      {
         "driver" : "bridge",
         "name" : "bridge"
      }
   ],
   "network_mode" : "default",
   "port_bindings" : [
      {
         "container_port" : 5800,
         "host_port" : 5800,
         "type" : "tcp"
      }
   ],
   "privileged" : false,
   "shortcut" : {
      "enable_shortcut" : false,
      "enable_status_page" : false,
      "enable_web_page" : false,
      "web_page_url" : ""
   },
   "use_host_network" : false,
   "volume_bindings" : [
      {
         "host_volume_file" : "/docker/appdata/crashplan-pro",
         "mount_point" : "/config",
         "type" : "rw"
      }
   ]
}

[jlesage]

You don't seem that have any volume mapping for the data to backup ?

[septeven]

Well that is exactly what I was thinking when looking at the config, but since I was not sure how it was before, I wasn't able to compare it, thus wasn't able to troubleshoot this.

I just wonder why this has changed since I updated the docker image as I have always done for years (following your instructions on the wiki here : https://github.com/jlesage/docker-crashplan-pro#synology), and I have never experienced such a problem.

When I first created the container a few years ago (I've kept a note with the command lines I used), I know that I used those tags regarding the volume :

    -v /volume1/docker/appdata/crashplan-pro:/config:rw \
    -v /volume1/:/volume1:ro \

Is it possible to fix it, mapping it again, and so the folders won't be marked as deleted on crasphlan, or do I have to re-upload everything (I am terrified writing this since we are talking about 4TB of data)

[jlesage]

You can use the Synology UI (Container Station) to add back the mappings.

However, note that the mapping /volume1/:/volume1:ro no longer works with recent Synology versions. You need instead to map folders under it. For example, you can map /volume1/Movies from the NAS to /volume1/Movies in container.

[septeven]

By chance, do you have any idea what could have caused this ? I mean again, everything was working fine until I update the image from 7.7.0 to 10.0.0 two days ago...

As for the change of mapping support by Synology, I didn't know. Since I'm using Crashplan, I've been backuping to Crashplan 4 folders :

• volume1/ BACKUPS
• volume1/DATA
• volume1/git
• volume1/web

That means I now have to add these 4 mappings instead of the volume1/ I used to map, is that correct ?

And what about Crashplan? Will that fix the problem automatically so I won't need any re-upload ?

(Thanks a lot Jocelyn!)

[jlesage]

By chance, do you have any idea what could have caused this ? I mean again, everything was working fine until I update the image from 7.7.0 to 10.0.0 two days ago...

I don't know... seems to be a glitch in the Synology upgrade procedure? To automatically upgrade the containers, you may want to check Watchtower: https://github.com/containrrr/watchtower

That means I now have to add these 4 mappings instead of the volume1/ I used to map, is that correct ?

Correct.

And what about Crashplan? Will that fix the problem automatically so I won't need any re-upload ?

Yes, this should fix the issue.

[septeven]

Thank you, it works, at least the folders are not empty anymore in Manage Files. I am scanning now, found my files back, only thing I'm still not sure at this exact moment is that it won't need to re-upload everything again.

[septeven]

Well, here is what I see now, what terrified me seems to happen.... is it going to upload everything again ??

[jlesage]

This part is confusing. That doesn't mean that everything is re-uploaded. Look at Tools->History, you should see very high "effective" rates, meaning that data has been found in cloud and no re-upload occurred.

[septeven]

Everything is okay now, thank you so much Jocelyn ! It took 2 days to scan and upload every not-already-backuped files but everything's back to normal now. Thank you!

[jlesage]

Great, happy to hear that everything works fine!