Squid

Icons once they are downloaded once should never attempt to download again. You would need to post your diagnostics after the following happens: - Icons are present, and then after a refresh the icons disappear, ideally without a reboot happening in between

You missed what I suggested. I was suggesting a NON locking cable. They are the only ones that are actually up to spec and an absolute ton of locking cables are not spec and are missing the internal bump with the result that they have lack luster results on some WD drives

WD40EFAX-68JH4N1 (disk 4) is having continual resets. SATA cabling sucks. Since this is a WD drive, you either want to use a SATA cable that if it has the locking header also has the internal "bump" on the interior of the connection. If you have no idea what I'm talking about you may be better off with a non-locking cable.

No solution. The problem is that both Plex and the docker subsystem will constantly access files. Drive spinning in and by itself is reliability wise the best thing for your spinner. For power consumption replace the cache drive with an SSD (or add the SSD as an additional cache pool and only keep the appdata / docker image on it.

DOCKER_IMAGE_FILE="/mnt/user/system/docker/docker.img" DOCKER_IMAGE_SIZE="75" Setting a 75Gig docker image is akin to taking your Ferrari down the block to pick up your mail. Sure it works, but it's massive overkill. The 75G also implies that you've had serious problems with the image filling up in the past. By and large, 99.99% of users will never even use the default 20G space. My suggestion is to either sort out why the image keeps filling up (in the past), or switch to a docker folder so that you don't need to ever worry about it again. (As an aside, 3G for the libvirt image is also overkill, and I can't think of anyone who has ever needed more than the default 1G) But, the real problem here is Dec 28 19:11:41 TheDoctor kernel: BTRFS critical (device sdo1): corrupt leaf: root=5 block=509462364160 slot=6 ino=496263061 file_offset=339968, invalid compression for file extent, have 136 expect range [0, 3] And because of the corruption the cache drive gets remounted as read-only and is causing your issues. I'm going to leave it to the resident guru @JorgeB to assist further in recovery on this.

That's pretty much a given because once appdata, the docker image etc is on the cache drive, it will stay up and running due to how Plex et al operate. On a default system, those shares are automatically created unless you override the locations with another share to use. Those 3 are set to use the cache drive, and this is how you want things set up appdata shareUseCache="only" # Share exists on cache domains shareUseCache="prefer" # Share exists on cache system shareUseCache="prefer" # Share exists on cache

Many containers (eg: 'arrs) also have additional options within their own settings to set the permissions on the particular files which they create. Set the UMASK etc within their settings, or use permissions of 0777 in the settings.

https://wiki.unraid.net/Manual/Changing_The_Flash_Device

And now it's working

Yes it did stop working. Thanks....

Reboot and see if it continues

Have you tried it again with a different flash drive?

Try making a change (any change) to settings - Network, revert and then reapply

Have you tried it yet?

You will need to reply back with your diagnostics

Only the "root" user has access to the webUI to manage the server All other users are used to access the files on the server via SMB, NFS etc

/etc/cron.d/root But usually you would manage cron jobs either via user scripts or by putting an applicable .cron file on the flash drive

It appears that you are running one or more docker containers on a dedicated IP address. Some users have the same or similar issues when doing this. You should try switching the network driver from macvlan to ipvlan in Settings - Docker (advanced view with the entire service stopped) and see if that fixes you up

If the Apps Tab says you're running on the Backup Server, then plugin installs, updates etc won't work, but the OS updates should work. Reboot everything network related including the server and try it all again.

How is the system booting? Via EFI/UEFI or legacy? Trying GUI boot mode or the normal boot mode... Any difference with Safe Mode being chosen?

By and large, the most common reason for a share being deleted is someone actually deleted it. Alternatively, some apps (eg: Plex et al) have options to automatically delete file(s) that haven't been accessed in a while Also, file system errors can make it *seem* like the share is gone when in reality the disk(s) are just corrupted and have errors on them. Diagnostics would help on this one

Why not just use the fan profile settings in the BIOS??? Built-in and not dependent upon any software.

Sans diagnostics, you're probably out of space in /tmp on the system. A reboot is going to be necessary to recover. Are you using Plex and transcoding to RAM (/tmp). Plex (as per usual) is a PITA and has a nasty habit of never deleting it's temporary transcode files until playback is finished which means that /tmp can quite easily (and quite quickly) fill up

Are you saying that the "Apps" page will work after you made the change? (And even after a reboot?) If so, there is nothing fundamentally wrong with the system as a whole. Plugin Updates in particular should definitely work... With current world events (unjust wars) and weather situations (North America), perhaps this is a blip. Where are you located?

Did you also move the RAID card over or did the new server have a RAID onboard and you then created a new JBOD arrays with it. RAID cards don't report the true serial numbers of the drives and basically append their own identifier to it. which is resulting in the system not identifying the drives as they were before. You should do a Tools - New Config. Then reassign all the drives into their appropriate places (make note of which is parity and which is data). You can also check off parity is already valid, but you should run a parity check regardless.