Squid

Try having it rebuild the disk again from parity, and if/when it fails and becomes disabled during the process, post your diagnostics

Hard to say without diagnostics and the specific share in question Internal IP

At what time roughly? Nov 21 02:46:34 ScorpionClaw kernel: sd 6:0:6:0: attempting task abort!scmd(0x0000000001303621), outstanding for 7027 ms & timeout 7000 ms Nov 21 02:46:34 ScorpionClaw kernel: sd 6:0:6:0: [sdi] tag#8877 CDB: opcode=0x85 85 06 20 00 d8 00 00 00 00 00 4f 00 c2 00 b0 00 Nov 21 02:46:34 ScorpionClaw kernel: scsi target6:0:6: handle(0x0010), sas_address(0x500056b35aa732c6), phy(6) Nov 21 02:46:34 ScorpionClaw kernel: scsi target6:0:6: enclosure logical id(0x500056b31234abff), slot(6) Nov 21 02:46:34 ScorpionClaw kernel: scsi target6:0:6: enclosure level(0x0001), connector name( ) Nov 21 02:46:34 ScorpionClaw kernel: sd 6:0:6:0: device_block, handle(0x0010) Nov 21 02:46:36 ScorpionClaw kernel: sd 6:0:6:0: task abort: SUCCESS scmd(0x0000000001303621) Nov 21 02:46:36 ScorpionClaw kernel: sd 6:0:6:0: device_unblock and setting to running, handle(0x0010) Nov 21 02:46:36 ScorpionClaw emhttpd: read SMART /dev/sdi Nov 21 02:46:38 ScorpionClaw emhttpd: spinning down /dev/sdc Nov 21 02:47:03 ScorpionClaw kernel: sd 6:0:7:0: attempting task abort!scmd(0x0000000050a47542), outstanding for 7048 ms & timeout 7000 ms Nov 21 02:47:03 ScorpionClaw kernel: sd 6:0:7:0: [sdj] tag#8887 CDB: opcode=0x85 85 06 20 00 d8 00 00 00 00 00 4f 00 c2 00 b0 00 Nov 21 02:47:03 ScorpionClaw kernel: scsi target6:0:7: handle(0x0011), sas_address(0x500056b35aa732c7), phy(7) Nov 21 02:47:03 ScorpionClaw kernel: scsi target6:0:7: enclosure logical id(0x500056b31234abff), slot(7) Nov 21 02:47:03 ScorpionClaw kernel: scsi target6:0:7: enclosure level(0x0001), connector name( ) Nov 21 02:47:03 ScorpionClaw kernel: sd 6:0:7:0: device_block, handle(0x0011) Nov 21 02:47:05 ScorpionClaw kernel: sd 6:0:7:0: task abort: SUCCESS scmd(0x0000000050a47542) Nov 21 02:47:05 ScorpionClaw kernel: sd 6:0:7:0: device_unblock and setting to running, handle(0x0011)

Look for a docker container that's continually restarting (The uptime for the container should show it)

Run the file system check against disk 5. https://docs.unraid.net/legacy/FAQ/check-disk-filesystems/?utm_source=google&utm_medium=cpc&utm_campaign=p-max-targeted-us-can&utm_content=&utm_term=&gad_source=1&gclid=CjwKCAiA9IC6BhA3EiwAsbltOAmKATlNgIX081zi2Gyh-KeUMdv8g81U89mplAq2KwMkwz4ZdQ8FaRoCZK8QAvD_BwE

Post your diagnostics

Did you switch the network type from the default of Bridge?

Can you reach it via 192.168.1.122? Or via //Tower-2 ?

https://macpaw.com/how-to/fix-error-code-36#:~:text=Get Info comments.-,What,-causes error code

/mnt/user/appdata/ But isn't that really what we are doing with /config? And nothing is "obscure" if something other than /config refers to /mnt/user/appdata/. That path gets changed to whatever is set as the user's appdata path. Nothing else. There's no guessing involved...

@ich777 I believe still has maintained containers that require direct disk access. We'll agree to disagree, especially since the automatic remapping of /config paths has been in place for a decade. The new thing is for anything that's not /config will get remapped by CA IF the value or default in the template refers to the default appdata path as shipped. In which case it will get changed to whatever the user has set. Same result. And that's the exact reason why CA will adjust the paths to match the user's environment. It's a rare occurrence where a template exists within Apps that is passed unchanged for one reason or another to dockerMan. And that is part of the success story of both CA and Unraid. Things get adjusted to suit.

Would be worthwhile to reseat the cabling to disk 6 & disk 4 -> they keep resetting off and on

Have you runn a memtest yet?

The code in question has been in since at least 2018 (I stopped at that point looking back further), and resolves the symlink. I'll see if it can get removed, but bear in mind that what it does show is technically correct.

To rule it out, have you run memtest for at least a single pass?

Which is why CA / dockerMan has to adjust the paths. Because if the user decides to map their default appdata path as "Appdata" instead of "appdata" now you've got two shares identically named. Or if you want it stored within a different share altogether. Or what about the templates where the template explicitly references /mnt/cache/appdata, but the user doesn't have a pool named "cache", so it gets created in RAM and subsequently lost without any adjustments happening? Or similarly where user shares are not enabled, should the template system have everything automatically going to RAM? But, for what it's worth, dockerMan (template editing screen) is dereferencing the path itself, and it is correct. The behaviour of /config entries automatically being overwritten has been in place for probably 10 years. But, let's use SearX as a better example. You've got /etc/. with a default value of /mnt/user/appdata/searxng/. For the users that have chosen to change their default appdata path to say /mnt/user/system/appdata or who have it on an unassigned device, that setting is going to wind up creating a new appdata share unless the user automatically changes it. dockerMan has been doing this forever on /config. CA just started on everything else for what is referring to the appdata share. (And inadvertently you found a bug, since CA only adjusted things in the value, not the default if there was no value) Shouldn't the OS automatically adjust the settings to match what the USER has specified? Or is the paths that the maintainer chosen for where to store the appdata and the references be what is forced onto every user, and effectively forcing them to conform?

For a mapping that is /config (ie: most container's appdata), then the template system automatically adjusts that host mapping to reflect whatever you have set in Settings, Docker Settings, default appdata path. Either way, what's the difference or trouble that you're having? On an exclusive share sitting on the cache drive, both references are identical and valid. For any default template that has a mapping that is not a container path of /config but has a default host path that is set to be the Unraid default path for docker appdata, then CA adjusts that path to match whatever you have currently as the default appdata path

Sorry about that guys. Fixed...

Is this still showing when you install from Apps? It should NEVER show if you install from Apps as the drop down is redundant, pointless, and makes no sense when using Apps

Try settings static DNS addresses of 208.67.222.222 and 208.67.220.220 within Settings - Network Settings

Your tunnel is blocking something. Or try disabling all your extensions in your browser and see what happens.

I'd need to see the entire debugging from CA on this... Click debugging on the left side

To elaborate on this point a bit more, a change in the template repository on GitHub -> eg: transferring the repository to another user, renaming the repository, or changing your username -> can be inferred to be either a completely innocent change, or could also be a result of a malicious actor and/or a breach of the GitHub account. To protect the integrity of the system and the user base, the automatic checks will always err on the side of security. IE: We will blacklist / remove the repository first and ask questions later... Andrew

What does Fix Common Problems (if installed) say? Try changing your DNS addresses in Settings - Network Settings to be 208.67.222.222 and 208.67.220.220

Last update to the stable version was April 28th. Last update to the "daily" version was today