Shonky

Live demo link in unRAID apps ( https://dash.mauz.io/ ) goes to possibly dangerous websites vie multiple redirects. Should be https://dash.mauz.dev/

Not sure exactly what fixed it for me but I can say that running the latest stable the issue has not appeared for quite some months now. I did make some minor changes to macvlan/ipvlan but seem to remember that didn't seem to help.

Well this docker template is not the same as the one I linked to. If you're having trouble with the other one then this thread is the wrong thread. The thread I linked I believe is the best and most up to date one. There have been a couple and also there have been significant changes to Crashplan over time e.g. the removal of the Home product.

Well firstly have you found the service.log.0 file and checked if it really is the same issue? Just because it's similar symptoms doesn't mean it's thae same problem. If it's the same problem go to the Docker tab then click the Crashplan then ">_ Console". Then you should be able to just "chmod 777 /usr/local/crashplan" without quotes and restore should just start from memory. Note that this is essentially a hack to make it work and possibly won't last if the container is restarted. The other container I use ended up getting a permanent fix.

Take a look at this. Could be the same or a similar thing. Check Crashplan's log files. It creates quite a few.

Did some more digging and found the code in /usr/local/emhttp/webGui/nchan/update1 #!/usr/bin/php -q <?PHP /* Copyright 2005-2021, Lime Technology * Copyright 2012-2021, Bergware International. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License version 2, * as published by the Free Software Foundation. * * The above copyright notice and this permission notice shall be included in * all copies or substantial portions of the Software. */ ?> <? $docroot = '/usr/local/emhttp'; $varroot = '/var/local/emhttp'; require_once "$docroot/webGui/include/publish.php"; while (true) { unset($memory,$sys,$rpms,$lsof); exec("grep -Po '^Mem(Total|Available):\s+\K\d+' /proc/meminfo",$memory); exec("df /boot /var/log /var/lib/docker|grep -Po '\d+%'",$sys); exec("sensors -uA 2>/dev/null|grep -Po 'fan\d_input: \K\d+'",$rpms); $info = max(round((1-$memory[1]/$memory[0])*100),0)."%\0".implode("\0",$sys); $rpms = count($rpms) ? implode(" RPM\0",$rpms).' RPM' : ''; $names = array_keys((array)parse_ini_file("$varroot/shares.ini")); exec("LANG='en_US.UTF8' lsof -Owl /mnt/disk[0-9]* 2>/dev/null|awk '/^shfs/ && \$0!~/\.AppleD(B|ouble)/ && \$5==\"REG\"'|awk -F/ '{print \$4}'",$lsof); $counts = array_count_values($lsof); $count = []; foreach ($names as $name) $count[] = $counts[$name] ?? 0; $count = implode("\0",$count); publish('update1', "$info\1$rpms\1$count"); sleep(5); } ?> My regex skills aren't the best so perhaps excluding the Apple files and just counting open files? But why does it even do this if there's no WebGui reading it?

Did you figure out what "feature" causes this? I see an lsof task running every 5-10 seconds as a process spawned by update1. I have made sure I closed all WebUI interfaces (closed browser completely, made sure no processes still running) but they persist. This is the command that keeps running sh -c LANG='en_US.UTF8' lsof -Owl /mnt/disk[0-9]* 2>/dev/null|awk '/^shfs/ && $0!~/\.AppleD(B|ouble)/ && $5=="REG"'|awk -F/ '{print $4}' I don't have any Apple devices so whilst mine's not pegging the CPU at 100% for extended periods it's not necessary. Just runs 100% for maybe a second each time. Seems to be look for hidden files left by Macs and then prints them somewhere. Seems kind of pointless to me. I see a sleep 2, so perhaps running every two seconds: ps aux | grep ls[o]f -A5 -B5 root 17957 0.0 0.1 88744 29040 ? SL Jul03 24:23 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/wg_poller root 17960 0.0 0.1 88744 29000 ? SL Jul03 6:40 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_1 root 17963 0.0 0.1 88944 29716 ? SL Jul03 34:08 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_2 root 17966 0.1 0.1 88884 29408 ? SL Jul03 64:21 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_3 root 18095 0.0 0.0 0 0 ? I 17:31 0:00 [kworker/2:0] root 18149 0.0 0.0 3936 2984 ? S 17:31 0:00 sh -c LANG='en_US.UTF8' lsof -Owl /mnt/disk[0-9]* 2>/dev/null|awk '/^shfs/ && $0!~/\.AppleD(B|ouble)/ && $5=="REG"'|awk -F/ '{print $4}' root 18150 13.0 0.0 5340 3292 ? S 17:31 0:00 lsof -Owl /mnt/disk1 /mnt/disk2 /mnt/disk3 /mnt/disk4 /mnt/disk5 root 18151 0.0 0.0 8376 2560 ? S 17:31 0:00 awk /^shfs/ && $0!~/\.AppleD(B|ouble)/ && $5=="REG" root 18152 0.0 0.0 8244 2496 ? S 17:31 0:00 awk -F/ {print $4} root 18155 0.0 0.0 2464 732 ? S 17:31 0:00 sleep 2 root 18156 0.0 0.0 4860 2908 pts/27 R+ 17:31 0:00 ps aux root 18157 0.0 0.0 3980 2228 pts/27 S+ 17:31 0:00 grep ls[o]f -A5 -B5

Right but the Change time is being updated (see original post) which appears to be what hashbackup is seeing.

If I knew I could hit it in a few days I would probably roll back to 6.8.3 and try, but mine's just as likely to run for 2 months without an issue so I think I prefer to go with 6.10-rc2 for now. One of those hard to prove a negative things. If it fails again I'll revert and/or try your suggestions. BTW: I don't really follow this ipvlan/macvlan thing but my 6.10-rc2 has a macvlan kernel module loaded (and no ipvlan)

Is this the right post? You say host access *disabled* but in the quote above you say "with host access": I don't have any bridging enabled but the host access does create some sort of bridge. I found firewall was complaining that my unRAID IP machine was changing between two MAC addresses which is bad (tm) so that's how I ended up with turning that host access thing off today.

6.9.2 was where I'd been for a long time with it occurring semi regularly. Upgraded to 6.10-rc2 just the other day and it happened within about 12ish hours. I don't think 6.10-rc2 is any worse, just luck of the draw. At this point the released 6.9.2 was just as bad so saying release vs unreleased isn't really a thing on my setup.

It did appear to be the file integrity plugin as updating one of the file date attributes resulting in hashbackup backing them up again. I've stopped the plugin for now.

I came across this solution separately, and then found this other thread just now. Seems like it could be a possible solution. My router (pfSense) was complaining about an IP having two different MAC addresses (the real hardware and a virtual interfaces called something like br0-shim but responds to ARP requests I presume resulting in packets to one IP coming in on two different network interfaces)

How did you go with this? I've been suffering this issue for a while and independently from this thread came across this as a possible cause. I've only been running a few hours and it can take anywhere between 12 hours and 30+ days for it to occur.

Turn cache off or if doing it on the machine itself, copy direct to /mnt/user0/...