tcharron

With no error messages anywhere, I wonder if it's the drive, or if the problem is in the controller/cables/driver... I guess I can remove it and test it in another system.

One of my drives suddenly just slowed down. It is operating at about 10% of what it was doing yesterday. I ran a diskspeed test, and the graph shows the impact. The logs attached will show that I also have a cache drive problem due to a bad cable, but this seems unrelated, as all of my other array drives are affected. Any ideas? tower-diagnostics-20201016-1644.zip

My docker.img was somehow corrupted. I deleted it and restored my dockers using CA, and all seems well.

So checked the cables and the device seems stable now. I was able to rebuild the drive. root@Tower:~# btrfs scrub status /mnt/cache UUID: 100735db-0e88-4450-a406-40f3efdd2bb7 Scrub started: Tue Jul 14 20:31:42 2020 Status: finished Duration: 0:16:16 Total to scrub: 434.15GiB Rate: 455.50MiB/s Error summary: verify=17806 csum=6157411 Corrected: 6175217 Uncorrectable: 0 Unverified: 0 root@Tower:~# Thanks for your help!

Actually.. When I try to get a smart report for sdm, it tells me that the drive is offline! This may be good news! Why doesn't the unraid interface show anywhere that the drive is gone?? I get (from the link you provided) that the error count is wrong, but a red ball on this page would go a long way...

So a run of 'btrfs scrub /mnt/cache' has found about a million uncorrectable errors within 30 seconds. Does this mean that my entire cache drive is toast, and now I need to rebuild it? Given it is a pool, I would have expected to be able to rebuild (much like when array drives fail), should any single drive have errors. Is there any way to do this? Can I just remove sdm and replace it?

tower-diagnostics-20200713-1449.zip

I just saw a huge amount of errors logged. I never got a warning or error from unraid about this, and the web interface shows nothing concerning. This is just a small portion of what I'm seeing flood my logs... Jul 13 14:26:42 Tower kernel: BTRFS error (device sdk1): bdev /dev/sdm1 errs: wr 323772515, rd 238527220, flush 476552, corrupt 0, gen 0 Jul 13 14:26:42 Tower kernel: BTRFS error (device sdk1): bdev /dev/sdm1 errs: wr 323772515, rd 238527221, flush 476552, corrupt 0, gen 0 Jul 13 14:26:42 Tower kernel: BTRFS error (device sdk1): bdev /dev/sdm1 errs: wr 323772515, rd 238527222, flush 476552, corrupt 0, gen 0 Jul 13 14:26:42 Tower kernel: BTRFS error (device sdk1): bdev /dev/sdm1 errs: wr 323772515, rd 238527223, flush 476552, corrupt 0, gen 0 Jul 13 14:26:42 Tower kernel: BTRFS error (device sdk1): bdev /dev/sdm1 errs: wr 323772515, rd 238527224, flush 476552, corrupt 0, gen 0 Jul 13 14:26:43 Tower kernel: BTRFS warning (device sdk1): lost page write due to IO error on /dev/sdm1 Jul 13 14:26:43 Tower kernel: BTRFS warning (device sdk1): lost page write due to IO error on /dev/sdm1 Jul 13 14:26:43 Tower kernel: BTRFS warning (device sdk1): lost page write due to IO error on /dev/sdm1 Jul 13 14:26:43 Tower kernel: BTRFS error (device sdk1): error writing primary super block to device 4 Jul 13 14:26:43 Tower kernel: BTRFS warning (device sdk1): lost page write due to IO error on /dev/sdm1 Jul 13 14:26:43 Tower kernel: BTRFS warning (device sdk1): lost page write due to IO error on /dev/sdm1 Jul 13 14:26:43 Tower kernel: BTRFS warning (device sdk1): lost page write due to IO error on /dev/sdm1 Jul 13 14:26:43 Tower kernel: BTRFS error (device sdk1): error writing primary super block to device 4 Jul 13 14:26:43 Tower kernel: BTRFS warning (device sdk1): lost page write due to IO error on /dev/sdm1 Jul 13 14:26:43 Tower kernel: BTRFS warning (device sdk1): lost page write due to IO error on /dev/sdm1 Jul 13 14:26:43 Tower kernel: BTRFS warning (device sdk1): lost page write due to IO error on /dev/sdm1 Jul 13 14:26:43 Tower kernel: BTRFS error (device sdk1): error writing primary super block to device 4 Jul 13 14:26:43 Tower kernel: BTRFS warning (device sdk1): lost page write due to IO error on /dev/sdm1 Jul 13 14:26:43 Tower kernel: BTRFS error (device sdk1): error writing primary super block to device 4 Jul 13 14:26:43 Tower kernel: BTRFS error (device sdk1): error writing primary super block to device 4 Jul 13 14:26:43 Tower kernel: BTRFS error (device sdk1): error writing primary super block to device 4 Jul 13 14:26:43 Tower kernel: BTRFS error (device sdk1): error writing primary super block to device 4 Jul 13 14:26:43 Tower kernel: BTRFS error (device sdk1): error writing primary super block to device 4 Here is the relevant drive information: DEVICE IDENTIFICATION TEMP. READS WRITES ERRORS FS SIZE USED FREE VIEW Cache KINGSTON_SV300S37A240G_50026B726706EDE1 - 240 GB (sdk) 25 C 41,038,636 27,137,657 0 btrfs 496 GB 210 GB 286 GB Browse /mnt/cache Cache 2 INTEL_SSDSC2KW512G8_PHLA8222024A512DGN - 512 GB (sdm) * 41,038,636 27,137,657 0 Device is part of cache pool Cache 3 KINGSTON_SV300S37A240G_50026B776407138B - 240 GB (sdn) 22 C 36,990,993 20,943,909 0 Device is part of cache pool This seems like a failing (failed?) drive, but I don't know if it is sdk or sdm, or if it is something else entirely. Any ideas?

I have found issues with getting Plex to run well. Sure I could probably get it going, but Serviio was just too familiar to me. I still run serviio on my unraid. I put this into /boot/config/setup-riftbit.sh docker pull riftbit/serviio docker run --name serviio_r -d --network host -p 23423:23423/tcp -p 23424:23424/tcp -p 8895:8895/tcp -p 1900:1900/udp -v /etc/localtime:/etc/localtime:ro -v /mnt/myapps/Serviio-riftbit/library:/opt/serviio/library:rw -v /mnt/user/unraid/Videos/Movies:/media/Movies:rw -v /mnt/user/unraid/Videos/Movies_Viewed:/media/Movies_Viewed:rw -v /mnt/user/unraid/Videos/Kids:/media/Kids:rw -v /mnt/user/unraid/videos_tv:/media/videos_tv:ro riftbit/serviio Then run it: /boot/config/setup-riftbit.sh The only downside is that it can't be configured from the docker page (even though it shows up there). If you ever want to change the setup, just destroy the container, edit the file, and run it again. Update: Here's a small script that will destroy the old container, update the image and then restart it: docker stop serviio_r docker rm serviio_r docker pull riftbit/serviio docker run --name serviio_r -d --network host -p 23423:23423/tcp -p 23424:23424/tcp -p 8895:8895/tcp -p 1900:1900/udp -v /etc/localtime:/etc/localtime:ro -v /mnt/myapps/Serviio-riftbit/library:/opt/serviio/library:rw -v /mnt/user/unraid/Videos/Movies:/media/Movies:rw -v /mnt/user/unraid/Videos/Movies_Viewed:/media/Movies_Viewed:rw -v /mnt/user/unraid/Videos/Kids:/media/Kids:rw -v /mnt/user/unraid/videos_tv:/media/videos_tv:ro riftbit/serviio

I got Serviio 2.0 working on my unraid (with my Sony Bravia TV). I based all of this on the riftbit serviio container. That has been updated 9 months ago (not sure if it will be supported beyond that, but it is 2.0). That container is described here (you don't need anything from this page -- it's just an fyi). https://registry.hub.docker.com/r/riftbit/serviio 1) Create a directory on your server that can be used to store library data. I chose to use /mnt/myapps/Serviio-riftbit. You should create a directory on your server before continuing. 2) Run the following commands. Replace the reference to the directory from step 1 with whatever directory you created. For each "-v" section below, map each of your media directories (I hope this part is self evident). The format is "-v [source directory]:[docker directory]:rw". You can probably use :ro at the end, but I haven't tried that to see if it causes any errors. I use RW since serviio can be configured to download metadata and subtitles etc docker pull riftbit/serviio docker run --name serviio_r -d --network host -p 23423:23423/tcp -p 23424:23424/tcp -p 8895:8895/tcp -p 1900:1900/udp -v /etc/localtime:/etc/localtime:ro -v /mnt/myapps/Serviio-riftbit/library:/opt/serviio/library:rw -v /mnt/user/unraid/Videos/Movies:/media/Movies:rw -v /mnt/user/unraid/Videos/Movies_Viewed:/media/Movies_Viewed:rw -v /mnt/user/unraid/Videos/Kids:/media/Kids:rw -v /mnt/user/unraid/videos_tv:/media/videos_tv:ro riftbit/serviio 3) Go to the docker page within your server. You will see a new "serviio_r" docker there. Disable any other serviio instances, or anything that uses conflicting ports (8895, 23424,23423) stop and restart the "serviio_r" docker 4) Navigate your browser to "[your unraid server]:23423/console 5) Configure serviio. In particular, add each of the media paths to the shared folders under the "Library" section. Note that the docker can not be configured or updated within the Unraid docker page. It can only be stopped/started/deleted (or the console accessed) from that page. If you want to make a change (for example, adding a new media directory), edit your command from step 2 (the first line is not needed again), delete the "serviio_r" docker (via the unraid Docker page), edit your script from step 2, and run it again. My experience is that Serviio configuration settings survive when I do this (although I have only tried it once or twice). I hope that this helps others! I'm not really intending to support this, but will try to do my best to help if I can. If I had more time and energy, the next logical step is to make this all configurable from within Unraid, without requiring the script. Tim

If you log in to your account at https://www.crashplanpro.com/app/#/console/ , what does it say? I wonder if somehow you have ended up with recent backups being somehow identified as a new device.

I am not trying to back up a network share. I am trying to back up local drives TO a network share. So effectively there is no way to use CrashPlan to back up local machines to my unraid server, even if I pay for CrashPlan.

I just installed CrashPlan Small Business on a windows machine, and this docker on my unraid box. For the life of me, I can't see how to establish a backup of the windows box to the unraid box. The only destination options I can see are "CrashPlan PRO Online" and "Add Local Destination". When I use the local destination option, I get an error if I select a network drive. I know that the peer to peer support has disappeared, but can't I at least back up to a network destination now? By the way, The OS in the logs reports as: /mnt/user/appdata/CrashPlanPRO/log/app.log:OS = Linux (4.15.0-60-generic, amd64) grep: /mnt/user/appdata/CrashPlanPRO/log/service.log: No such file or directory

I just had a cache drive fail. My former configuration was 3 240G SSD drives. That showed 360G of usable space After the failure of one drive, it still showed 360G usable. I figured that was ok, as the data was all there (but no longer protected). I replaced the bad drive with a 512G drive. I expected this to increase the capacity from 360G to 480G. This expectation was confirmed with the calculator at http://carfax.org.uk/btrfs-usage/. That calculator told me that 32G would go unused. This is presumably since everything written to the 2 240G drives would be duplicated on the 512G, with using 480G (and hence 32G left over). In fact, unraid reports that I now have an available cache pool of 496G. This doesn't make sense to me. What am I missing?

Yeah... as soon as I saw it I knew what was going on. I think that the entire idea of having things auto-installed from my flash drive via auto_install and a line in my go file was probably something that I added 5 years ago or so. It worked well for a very long time, and then was was long forgotten but survived the various upgrades along the way. My point in sharing it here was just to help anyone else figure it out, as I found a few threads with similar problems. The generallly accepted solution was to do a clean install to a new USB key -- neither of which is required with the above knowledge.