Squid

Good catch. Updating FCP to support multiple IRQ's being disabled. ty

Quick scan before the diagnostics / docker screen shot shows the following: [Fatal] ConsoleApp: EPIC FAIL! Probably not much comfort, but if you're going to fail, at least go all out and do it EPICally! But it might be related to [v2.0.0.4949] System.Data.SQLite.SQLiteException (0x80004005): database or disk is full The diagnostics would tell me.

Click on the docker tab and do the screen shot.

I'm assuming that the apps are appearing within the docker tab. Wouldn't be a bad idea to post up the following: A screenshot of the docker tab showing the apps and the various mountings, etc. The log's from the a container. Another set of diagnostics. But, push comes to shove, with everything that happened on the cache drive, it really wouldn't surprise me if you're going to be forced to start the appdata over again from scratch (unless you've got a backup). But lets see where the above takes us.

I missed that one Always something simple.

The ASM1061 should be supported AFAIK. Check the boot order when you have drives connected to them.

https://forums.lime-technology.com/topic/57181-real-docker-faq/?page=2#comment-566086

Check out the docker faq which has a few entries on this sibject Sent from my LG-D852 using Tapatalk

Best to post in the devpack thread and let[mention=6013]dlandon[/mention] know about it which package is messing up (if you can narrow it down) Sent from my LG-D852 using Tapatalk

Simple solution is to boot into safe mode. If its all good, then its a plugin causing you grief.

Without a cache drive, anytime you've got major hard drive activity (ie: download finished and unpacking / repairing followed by moving into final place), you're going to wind up seeing slowdowns. No real solution as unRaid's strong point is not ultra fast writes to the array.

Something using int 16 is getting disabled. If it winds up being your hard drive controller, then things will massively slow down. If its something else not as important than its not such a huge deal.

Beautiful thing about unRaid is that every install is a fresh install. If you managed somehow to delete a system file, a reboot will automatically get it back. Worst case scenario is that if something you installed via the devpack plugin would be to delete devpack.plg (or whatever its called) from /config/plugins on the flash drive and boot.

Someone else with no vowels

Yeah I've heard that before. That the FreeNAS forums are pompous (not quite sure if that's the right word for it though ) to say the least Sent from my LG-D852 using Tapatalk

Could be as simple as Plex needing to transcode, but because a parity check was underway that you just hit some bottlenecks. IE: if this happened right before you grabbed diagnostics, nothing really jumps out. The logs from Plex might have something.

All the sr0 errors relate to your DVD drive. (Bad disk?) Appears that the call trace happens if you eject the disk, and a process tries to get the directory contents of the empty drive. IE: nothing to worry about. The sdk errors all refer to your goFlex drive. Could be a bad drive (or on its way out), or you could try another usb port (USB2<-->USB3)

Right click, properties, scan for errors. Barring that, redo the bz files per above

You really should post your diagnostics though.

Just to give you a hand with this without directly being involved, dockerMan on appdata references automatically creates the folders necessary. Which means that the appdata winds up getting created in RAM.

Probably a stupid question, but are you also passing through the audio portion of the card?

Sorry. Still learning your Kung Fu. I'm just a grasshopper. But, here's why mover isn't appearing. /mnt/user0 never got mounted, even though the cache drive did. I suspect that a reboot might fix it all up, since FCP isn't complaining about the cache being unmountable. Aug 12 14:31:46 Tower emhttp: shcmd (860): mkdir -p /mnt/cache Aug 12 14:31:46 Tower emhttp: shcmd (861): set -o pipefail ; mount -t btrfs -o noatime,nodiratime -U 06e1ae7a-7152-48cf-8d36-0ce0eba6224b /mnt/cache |& logger Aug 12 14:31:46 Tower kernel: BTRFS info (device sdh1): disk space caching is enabled Aug 12 14:31:46 Tower kernel: BTRFS info (device sdh1): has skinny extents Aug 12 14:31:46 Tower kernel: BTRFS info (device sdh1): detected SSD devices, enabling SSD mode Aug 12 14:31:46 Tower emhttp: shcmd (862): sync Aug 12 14:31:46 Tower emhttp: shcmd (863): mkdir /mnt/user Aug 12 14:31:46 Tower emhttp: shcmd (864): /usr/local/sbin/shfs /mnt/user -disks 30 -o noatime,big_writes,allow_other -o remember=330 |& logger Aug 12 14:31:46 Tower emhttp: shcmd (865): rm -f /boot/config/plugins/dynamix/mover.cron Aug 12 14:31:46 Tower emhttp: shcmd (866): /usr/local/sbin/update_cron &> /dev/null

Best for @johnnie.black to answer: Aug 12 14:22:40 Tower emhttp: shcmd (82): mkdir -p /mnt/cache Aug 12 14:22:40 Tower emhttp: mount error: Too many misplaced devices: 1 Aug 12 14:22:40 Tower emhttp: shcmd (83): umount /mnt/cache |& logger

Implication is that the flashdrive has some corruption on it. Toss it into a windows box and check the filesystem on it. If that doesn't get you anywhere, download unRaid again from Limetech's website, and overwrite all the bz* files in the root of the flash with ones from the downloaded zip and try it again.

Machine check event: mce log only logged this: Aug 13 11:43:06 Moya root: mcelog: Family 6 Model 92 CPU: only decoding architectural errors First time I've ever seen anything that terse. But it may be because mcelog was installed when the errors happened. Reboot, and the next time it pops up, we should have something better to go on. Shares: Is the moya diagnostics from after a reboot? Was everything still running at the time? The "Tower" diagnostics are completely empty for some weird reason, but probably related to all the errors in the diagnostics.zip file which seems to imply that the flash drive dropped offline. Move the flash drive to a different controller (USB2 <--> USB3)