beardedpants

Well it looks like 4.7 isn't even out yet. They're pushing it starting May 16th as an automatic update. For whatever reason, it sees Docker containers/BSD jails as a platform that can't automatically update the app. I'm sure this will be resolved before the 16th.

I don't think it has anything to do with the kernel or glibc version, we're fine there. Rather, it's the version of the crashplan app itself. Search for 'CrashPlan' in the build log. It's version 4.6.0, which is going unsupported on May 16th.

I also got the email. Settings > Account tab on the container GUI says the version is 4.6, at least for me.

An update on this, and for anyone having a similar issue: The scheduled scan is indeed running, just very quiet about it. I happened to be in the basement on Monday evening and noticed my disk access lights flashing (unusual, single user server). Then I remembered what day and time it was. I opened a telnet terminal to check top and sure enough, the bunker script was busy running. There was nothing in the syslog about the scan starting, and nothing on the GUI to indicate a scan was running. This box did have a red translucent box over it while the scan was running. Is that the indication a scheduled scan is running?

Is there any obvious reason why scheduled integrity checking stopped working for me? I'm running the latest version, but this problem has existed for the past couple of versions. I wish I knew exactly when it stopped working, but I don't remember. My schedule is set to run weekly on Monday at 19:00. As far as I can tell, a scan is never even attempted. There are no entries for bunker in the syslog, good nor bad. Things I've tried: Removing all hashes and rebuilding, multiple times. Uninstalling the plugin and deleting the /boot/config/plugins/dynamix.file.integrity/ directory. Switching algorithms from BLAKE2 to SHA2 The scheduled time does not conflict with anything else, if that even matters. It did actually work for the first few weeks after I set it up,

I rebooted yesterday to set my tmpfs to 256M, so my log isn't full yet, but: root@TOWER:/# du -sm /var/log/* 0 /var/log/btmp 0 /var/log/cron 0 /var/log/debug 1 /var/log/dmesg 0 /var/log/docker.log 0 /var/log/faillog 1 /var/log/lastlog 0 /var/log/libvirt 0 /var/log/maillog 0 /var/log/messages 0 /var/log/nfsd 3 /var/log/packages 0 /var/log/plugins 0 /var/log/removed_packages 0 /var/log/removed_scripts 14 /var/log/sa 1 /var/log/samba 1 /var/log/scripts 0 /var/log/secure 1 /var/log/setup 0 /var/log/spooler 1 /var/log/syslog 1 /var/log/wtmp root@TOWER:/# du -sm /var/log/sa/* 5 /var/log/sa/sa20 7 /var/log/sa/sa21 3 /var/log/sa/sa22

I have the same issue, except mine reaches 100% in a couple of days, not immediately. I know that the log partition is tmpfs on ramdisk and that a reset will clear it, but does having the partition 100% filled negatively affect it, i.e., does logging still work?

Is Crashplan-Desktop currently broken? I'm getting the 'disconnected from backup engine' message from the GUI. I want to make sure it's nothing wrong on my end. Thanks