kenshinx34

Second try is a charm. I tore it all down, removed all the configs. Rebuilt it from scratch and it works great. Thanks!

Could you explain the click on icon method for adding ram? I feel really dumb. I would just ssh in and update the /bin/run.conf

I gave mine 4gb of ram and nothing I still get the same error as I did before.

Here's a screenshot for reference. I'm currently running updated unraid with the most current docker build of crashplan.

I also have the same issue with Crashplan becoming disconnected after 1 minute or so. It just started since this last update. Any ideas?

If I really don't want to add a cache, is it necessary? or am I fine just doing it to the normal array and just lose the speed and performance gains?

I'm going to ask a dumb question that I couldn't find the answer to anywhere, but I'm sure exists. Feel feel to just point me to a link. Why should we put the docker setup on the cache drive? Is it a performance reason (faster speeds)? Is it so we aren't constantly spinning up and down multiple drives in the array? Is it so we don't constantly write data to the disk & parity? Is there any harm in putting in on the array? If we do use a cache drive what's the risk of the cache dying with the docker/crashplan data on it? Do you automatically have the cache set to backup to your array at night? Again, I apologize if this has been asked before. I just would like to understand a bit better the proper use of the cache drive before I sacrifice a sata port for cache disk. -Eric

Perfect thanks!

This is probably just a crazy coincidence. I have never had RAM ever go bad on me. I updated to 6.1.8 on both of my Unraid servers and in the same week I had two completely different Unraid builds RAM go bad. Can an OS corrupt RAM, or is this just some crazy coincidence? One stick of RAM is 2yrs + old, and the other is <6months. One is 2GB, the other is 8GB. I get correlation does not imply causation, it just seems too hard to ignore that two completely different machines, with entirely different workloads, hardware specs would go bad after the same upgrade within a week of one another. Has anyone had file corruption with bad ram? Would parity checks catch this?

Totally the memory. I am an idiot. How much should I worry about the files that I copied over? If they copied okay what do you think the chances of corruption are/were?

I'm making the move as well to Windows 10. Since v6.1.* I've had nothing but problems, docker won't stay alive for more a day, and I can't even copy large files off without unraid dying (I suspect a kernel issue but no one has replied to my forum post). I've used unraid for years and years and really like it, but I can't deal with the instability.

Well unraid is just about unusable now. I'm really surprised no one has replied to this post.

Also the CPU is at max 15% utilized so it is not taxed at all and airflow is great.

Hey All, I'm a long time Unraid user and have not had this type of error before. When transferring files, at some point during the transfer Windows experiences "an unexpected network error". After receiving this error I could no longer ping Unraid, SSH, connect to shares, or pretty much anything. It was clear that Unraid was still on, but nothing was responding. The only way to get it out of this was to hard power it off. This obviously isn't good and forces a parity check each time. I'm currently running the latest build of Unraid 6.1.7. Docker is not running and the only other plugin I have running is Sleep (other than the stock plugins). The drives are all reporting clean SMART stats, and the pool is 6 drives (10TB total) with about 70% utilization. Here's my system build: M/B: ASUSTeK Computer INC. - M4A88T-M CPU: AMD Athlon II X3 450 @ 3200 HVM: Disabled IOMMU: Disabled Cache: 384 kB, 1536 kB Memory: 6144 MB (max. installable capacity 16 GB) Network: eth0: 1000Mb/s - Full Duplex Kernel: Linux 4.1.15-unRAID x86_64 OpenSSL: 1.0.1q After digging deeper and tailing syslog during a transfer here's what I found (see the attached two logs). At first I thought it had something to do with AFP so I disabled the share with the apple shares. Still the same issue. The transfers range anywhere from 50GB to 250GB which is big, but has never been a problem in the past. This machine has been incredibly stable (uptimes of 8 months no problem). I haven't made any hardware changes recently either. Any help would be awesome! First.txt Second.txt

I just installed the Crashplan & Crashplan Desktop docker images and am having an issue with a "Bus error" *** Running /etc/my_init.d/config.sh... Current default time zone: 'America/Los_Angeles' Local time is now: Sat Jan 2 18:10:29 PST 2016. Universal Time is now: Sun Jan 3 02:10:29 UTC 2016. cp: cannot stat ‘/root/wallpapers/*’: No such file or directory /etc/my_init.d/config.sh: line 17: 30 [b]Bus error[/b] /usr/bin/supervisord -c /opt/supervisord.conf Now here's the strange part. I spent the last week troubleshooting a docker/owncloud problem where a "Bus error" was an issue while trying to run an update within docker/owncloud. I would say this was just my problem as it seems no one else has stumble across it from the lack of Google answers. However these are on two completely separate unraid builds that are both experiencing "Bus errors". Here's my Unraid version and build information: Version: 6.0.1 Model: N/A M/B: ASUSTeK Computer INC. - M4A88T-M CPU: AMD Athlon(tm) II X3 450 @ 3200 HVM: Disabled IOMMU: Disabled Cache: 384 kB, 1536 kB Memory: 6144 MB (max. installable capacity 16 GB) Network: eth0: 1000Mb/s - Full Duplex Kernel: Linux 4.0.4-unRAID x86_64 OpenSSL: 1.0.1o Uptime:29 days Also after checking my main unraid log I would get the following line repeating while the docker containers were running Jan 2 18:18:12 Server kernel: BTRFS warning (device loop0): csum failed ino 19263 off 10285056 csum 3357241515 expected csum 2995147020 With some Googling here's what I've found so far although I'm not sure how to use it: https://lime-technology.com/forum/index.php?topic=40960.30 Any help would be great!