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 had this same problem recently and went nuts trying to figure it out. For me it happened with my two WD Green data drives (both WD20EZRX). The errors were really intermittent. One thing that would always trigger them was running a check with the dynamix file integrity plugin, I'm assuming because of the nature of that workload. First I swapped all my sata cables with brand new ones, still had the problem. Then I swapped the backplane, no help. Going further, I plugged the drives straight into the motherboard (Asrock H97 Pro4)...and no luck. The thought of RMA'ing the board was a nightmare, so I stepped away from it for a while. After more research and troubleshooting, it turned out to be a combination of NCQ, WD Green drives, and the Intel controller. The green's just didn't like having NCQ enabled on the motherboard controller. My WD Black and Seagate were fine. I ran with NCQ disabled for a few days, no errors in the log. The write speeds were worse with NCQ disabled, so I grabbed an extra Dell Perc H310 card from work and flashed it to the lsi IT firmware to turn it into an HBA. I plugged all my drives into the card and enabled NCQ. It's coming up on 2 weeks error free this way with great performance. Long winded, I apologize. Try messing around with the Force NCQ Disabled setting.

In one of his recent videos, the 100TB @ 1 GB/s one, he mentioned working with the Lime Tech guys directly on a special build with tweaked Samba settings.

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