Squid

done

Yeah, I don't see it in there. See if it happens again then post diagnostics before rebooting.

IMO since you're using a Kingston Flash it should be fine. USB2 ports generally are far more reliable on any given system / OS than USB3. It's a try and see type situation.

Dec 29 10:16:30 MyUnRAID emhttpd: shcmd (38): mount -t btrfs -o noatime,nodiratime /dev/sdc1 /mnt/cache Dec 29 10:16:30 MyUnRAID root: mount: /mnt/cache: wrong fs type, bad option, bad superblock on /dev/sdc1, missing codepage or helper program, or other error. Dec 29 10:16:30 MyUnRAID emhttpd: shcmd (38): exit status: 32 Dec 29 10:16:30 MyUnRAID emhttpd: /mnt/cache mount error: No file system Dec 29 10:16:30 MyUnRAID emhttpd: shcmd (39): umount /mnt/cache This looks to be the root of the problem. I'm assuming that the cache drive should have file(s) on it?

Not that I use plex, but do you have access to the PlexPass specific features?

Yup

Changed Status to Closed

Moved this to General Support as it's more appropriate there

It's not a defect. What's happened is that your flash drive is either pooched or dropped offline. Try a different port (ideally USB2)

It's not a defect. What's happened is that your flash drive is either pooched or dropped offline. Try a different port (ideally USB2)

Post your diagnostics before you reboot (Tools - Diagnostics)

One idea is that your cache drive has been mounted read-only Diagnostics would show that...

No, it requires a format so you'd have to copy everything you want onto the array and then switch the format and copy it back. @johnnie.black though would be able to advise on the actual issue with the cache drive (as stated, I don't like to advise on btrfs issues)

Diagnostics are after the reboot, so nothing of any interest in them. If this happens again, then grab a new set of diagnostics before you reboot and we'll be able to see exactly what happened and advise on the most appropriate course of action

First thing to always try is to run memtest from the boot menu for at least a pass or two.

Just for future reference, it would have been far easier instead to go to Apps, Previous Apps and check off whatever you wanted and hit install.

Rather than @pluginCop handling this via moderation of the online lists, I updated FCP to test for the various scenarios of one installed and not the other.

If you move from /mnt/disk1/share/filename to /mnt/user/share/filename (expecting the file to stay in the same share, but move to a different disk due to include / exclude rules), you will actually corrupt the file because at the end of the day, /mnt/disk1/share/filename and /mnt/user/share/filename is actually the same path to the source and the OS attempts to read the file while it's writing to the identical file. Net result is that the file gets corrupted. Its not a bug in the traditional sense, as by referencing disk1 and the same share via user you are bypassing the system. Hence why you should never mix disk references and share references (/mnt/diskX and /mnt/user) in the same command or operation.

You need to upgrade unraid to at least 6.7

The one on the cache drive probably was the good one. When duplicated files exist in the system, and you access them via /mnt/user/domains (eg), it goes in alphabetical order in finding the one to use (ie: cache, disk1, disk2 etc) What is the use cache setting for the domains share? Normally, it would be use cache:prefer

Your problem is because of an underlying problem on the cache filesystem, the docker.img is getting remounted as read-only Dec 23 13:58:27 Gateway kernel: BTRFS warning (device sdk1): sdk1 checksum verify failed on 1037221888 wanted 5771E135 found 6AAAD160 level 0 Dec 23 13:58:27 Gateway kernel: print_req_error: I/O error, dev loop2, sector 0 Dec 23 13:58:27 Gateway kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 0, rd 0, flush 1, corrupt 0, gen 0 Dec 23 13:58:27 Gateway kernel: BTRFS warning (device loop2): chunk 13631488 missing 1 devices, max tolerance is 0 for writeable mount Dec 23 13:58:27 Gateway kernel: BTRFS: error (device loop2) in write_all_supers:3716: errno=-5 IO failure (errors while submitting device barriers.) Dec 23 13:58:27 Gateway kernel: BTRFS info (device loop2): forced readonly Since it's BTRFS, I'm going to bow out on the filesystem repair, as I know squat about it, but I do recommend XFS as the filesystem if you have no intent to upgrade to a cache pool

Set in the network.cfg again, USE_DHCP6[0] to be "no" Then, ethtool should show an IP in the diagnostics (previously it was simply showing the IPv6), and with luck you'll be able to just type in the appropriate IP and go from there

Yeah, that's expected since you were using SSL. You can set it back to auto. Have you tried Safe Mode yet? Since you're using IPv6 exclusively, I'm not really sure where to go from here. The only other thing I can suggest is to delete the contents of ssh / ssl from /config on the flash (they'll get regenerated automatically), but from looking at your go file, you're adding in your own keys.

Now there's an example of someone who is not utilizing containers to their full extent (or has a boring server )

Or you are having them backup at 5am daily via the plugin