Squid

Yes

QFlood is running through another container for it's network (ie: it's not in bridge mode). Port mapping only works in bridge mode.

You might also want to try installing Dynamix Folder Caching to help things out a a bit

Since I forgot to post about it, yesterday's update for the Upgrade Assistant tests for IOMMU enabled and the tg3 driver running, so that you can decide whether or not to upgrade to 6.10.2

Just delete that file. It will be corrupted however, but if that's the only one listed, then don't worry about it.

https://wiki.unraid.net/My_Servers#:~:text=access the webgui.-,Unraid 6.10,not the default of 443)

You need to post your diagnostics. It's probably happening before mcelog is getting installed

Those 3 files are definitely corrupted. Delete them

Each page utilizes it's own .txt file, along with translations.txt CA is somewhat unique that it uses apps.txt, docker.txt and translations.txt It never touches plugins.txt That being said, Uninstall was missing from the en_US apps.txt so it'll be available to translate on the next round. One difference between the OS itself and any given plugin is that the OS is able to be "scraped" for what translations need to be done and the en_US files are updated automatically. Plugins do not have this luxury.

Thanks. I found "Install" earlier today doing something different, but didn't know about "Trends" - It is now set to be translated on the next rev. That all being said, every translation available for the OS is missing certain phrases. There isn't any which is 100% complete, and in the case of a missing translation the system will always display the English phrase

Apps, previous apps, reinstall jelly fin and fix the error. Not an OS issue because due to the failed docker run command the app is no longer actually installed. Prev apps gets the template back the way it was last saved

What language is the OS running in? Are you running the OS in English and the browser is automatically translating the content to your language of choice? The latter is NOT supported and will definitely result in display aberrations, as there's not much I can do about it. There is 100% no English text (OS running in English) that says "OFFICIALI" or "INSTALLEDDD"

Network failure *implies* an issue with your configuration (wrong DNS addresses / gateway) or the date & time completely wrong etc.

The emulated drive is the result of the mathematical equation resulting from reading the contents of all the other drives and calculating what that drive should be. https://wiki.unraid.net/Parity

Post your diagnostics. Also, are you running a ProLiant?

Similar issues (no IPv4 address) don't necessarily mean same problem. Posting your diagnostics will tell the entire story

Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_Name -- == -- == -- == == == -- -- -- -- -- --------------- -------------------- 60 00 28 00 00 00 01 80 12 b6 88 40 00 43d+11:57:14.120 READ FPDMA QUEUED ea 00 00 00 00 00 00 00 00 00 00 00 00 43d+11:57:13.644 FLUSH CACHE EXT 61 01 20 00 20 00 02 04 77 dc c0 40 00 43d+11:57:04.705 WRITE FPDMA QUEUED 61 04 00 00 18 00 02 04 77 d8 c0 40 00 43d+11:57:04.705 WRITE FPDMA QUEUED 61 04 00 00 10 00 02 04 77 d4 c0 40 00 43d+11:57:04.705 WRITE FPDMA QUEUED Error 2 [1] occurred at disk power-on lifetime: 17515 hours (729 days + 19 hours) Reseat the cabling. Also, trimming every hour is going to decrease the lifetime of the SSD. Once a week is more than sufficient.

Million variables. Internet speed, your CPU is 11 years old, size of files, whether your friend is in Plex as a Family member or a friend (without a plex pass membership) etc etc.

You would copy all the data from the emulated drive to one (or more) of the other drives (Use Dynamix File Manager). Then you would do a New Config, reassign all the drives excluding the one you're removing and rebuild the parity information.

Shot in the dark, switch from using a docker image file to instead using a docker folder. In theory it shouldn't actually make any difference, but trouble with other users using a ZFS unassigned device to store an image and it doesn't work whereas a folder does. Not that you're using ZFS, but doesn't hurt to try it. Settings - Docker, switch the type then Apps - Previous Apps and check off what you want.

May 27 23:02:53 CHIA0 kernel: megaraid_sas 0000:0d:00.0: megasas_disable_intr_fusion is called outbound_intr_mask:0x40000009 May 27 23:02:53 CHIA0 kernel: megaraid_sas 0000:0d:00.0: FW in FAULT state Fault code:0x10000 subcode:0x0 func:megasas_wait_for_outstanding_fusion May 27 23:02:53 CHIA0 kernel: megaraid_sas 0000:0d:00.0: resetting fusion adapter scsi1. May 27 23:02:53 CHIA0 kernel: megaraid_sas 0000:0d:00.0: Outstanding fastpath IOs: 0 May 27 23:02:53 CHIA0 kernel: megaraid_sas 0000:0d:00.0: Reset not supported, killing adapter scsi1. Looks like a firmware fault in the controller resulted in it killing itself off which then resulted in a ton of errors on each drive May 27 23:02:53 CHIA0 kernel: sd 1:0:79:0: [sde] tag#505 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=DRIVER_OK cmd_age=0s May 27 23:02:53 CHIA0 kernel: sd 1:0:88:0: [sdn] tag#58 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=DRIVER_OK cmd_age=0s May 27 23:02:53 CHIA0 kernel: sd 1:0:88:0: [sdn] tag#58 CDB: opcode=0x88 88 00 00 00 00 06 5d df ff 80 00 00 00 08 00 00 May 27 23:02:53 CHIA0 kernel: sd 1:0:84:0: [sdj] tag#506 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=DRIVER_OK cmd_age=0s May 27 23:02:53 CHIA0 kernel: sd 1:0:84:0: [sdj] tag#506 CDB: opcode=0x88 88 00 00 00 00 06 5d df ff 80 00 00 00 08 00 00 May 27 23:02:53 CHIA0 kernel: blk_update_request: I/O error, dev sdj, sector 27344764800 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 Which ultimately led to the OS not being able to utilize the drives May 27 23:03:06 CHIA0 emhttpd: device /dev/sdq problem getting id Complete shot in the dark, but update / reflash the firmware on the controller.

What are these lines in your diagnostics about? May 27 14:56:19 Media webGUI: Unsuccessful login user root from 100.81.154.14 May 27 14:56:24 Media webGUI: Successful login user root from 100.81.154.14 Not necessarily a problem, but 100.x.x.x. is usually reserved for CGNAT and isn't something you see every day. You are also having disconnects on the drive(s). Reseat the cabling. In extreme cases, this can cause what you're seeing.

Strange, and IMO not particularly possible with your system set up with static IPs and DNS First thing I'd try doing is reset the router, switches etc then reboot the server Then if it fails again try pinging 8.8.8.8 and then post your diagnostics before stopping / starting docker so we can see the state of the system while it's failed.

May 26 11:01:06 Tower mcelog: failed to prefill DIMM database from DMI data May 26 11:01:06 Tower mcelog: Kernel does not support page offline interface More than likely not an issue and safe to ignore, but maybe a BIOS update would solve it

Not sure if you're aware or not, but Apple deprecated AFP with OS X Mavericks in 2013 in favour of SMB.