Squid

What you really need to do is enable the mirror to flash of the syslog, then shutdown. After that, then post the resulting file from the flash drive. https://wiki.unraid.net/Manual/Troubleshooting#Persistent_Logs_.28Syslog_server.29

You have to add a tag after the repository when editing the template eg: linuxserver/habridge:v5.4.0-ls79 https://hub.docker.com/r/linuxserver/habridge/tags

Updated to handle the non-conforming version string used by MyServers

post your diagnostics

Reboot

AFAIK that shouldn't be possible. But, for me to find out what's going on in this case (since the unraid spinner won't disappear) In your browser, navigate to https://xxxxxxxxxxxxxxx.unraid.net/Apps/ca_settings (capitalization of "Apps" is important) Enable debugging. Then "Apply" and "Done" You'll wind up back at CA If you spinner does NOT disappear within 5 minutes, then cp /tmp/CA_logs/ca_log.txt /boot then upload ca_log.txt on the flash drive here along with your diagnostics

Did you run make_bootable.bat on the flash drive? Is the boot order correct?

@dlandon

You can also click Show Docker Allocations when installing to show the ports currently in use

What's up with this? Sep 22 06:27:50 Tower unassigned.devices: Successfully mounted '//10.10.1.233/appdata' on '/mnt/remotes/10.10.1.233_appdata'. Sep 22 06:27:50 Tower unassigned.devices: Adding SMB share '10.10.1.233_appdata'. Sep 22 06:29:05 Tower unassigned.devices: Removing Remote SMB/NFS share '//10.10.1.233/appdata'... Sep 22 06:29:05 Tower unassigned.devices: Unmounting Remote SMB/NFS Share '//10.10.1.233/appdata'... Sep 22 06:29:05 Tower unassigned.devices: Synching file system on '/mnt/remotes/10.10.1.233_appdata'. Sep 22 06:29:05 Tower unassigned.devices: Unmount cmd: /sbin/umount -t cifs '//10.10.1.233/appdata' 2>&1 Sep 22 06:29:05 Tower unassigned.devices: Successfully unmounted '//10.10.1.233/appdata' Sep 22 06:29:05 Tower unassigned.devices: Removing SMB share '10.10.1.233_appdata' Sep 22 06:29:08 Tower unassigned.devices: Removing configuration '//10.10.1.233/appdata'.

Post a screen shot... (along with your diagnostics)

Yeah, it's a yes and no thing (and the OS itself is also guilty of it). FCP is seeing that the docker "image" (in this case your nvme) is over it's arbitrary limit of (IIRC) 75%, and letting you know about it. The OS is even worse when using a folder and it goes over the limits set in Settings - Disk Settings. You get notified about the cache drive getting full and the "image" getting full. (I've already got an issue raised on an internal reporting system for this) Ignore the error from FCP

By and large, every app within CA maintains their settings outside of the docker.img (or folder) and keeps them within the appdata share. This allows you to easily recreate the image (or switch to a folder) by simply creating the docker folder and then reinstalling everything via Apps - Previous Apps. Odds are excellent that you'll never even notice that you migrated over.

Unraid identifies exclusively by the serial number. It appears based upon the Model number you listed that they are "Water Panther Drives". These are refurbished white-label drives sold by a 3rd party manufactured by either Seagate, Western Digital, etc based upon how many they can purchase at the price point they are after. I'd complain to White Panther. You might however have success by enabling "Display World Wide Name" in Settings - Display Settings

Changing the port via the go file does not work for quite a while. Settings, Management Settings. If fix common problems is complaining that you're trying to do it via "go", then edit /config/go on the flash drive using any editor (Notepad will work just fine)

The specific test actually is a test for if the drive is read-only or completely full. It writes a 4 byte file to the drive (which in reality takes up 4k on the drive). Is the drive formatted btrfs or xfs?

I just assumed the logs got cut off. Corruption exists on drive 4 (partial explanation for no containers), and if the server hasn't been powered off and cabling reseated, then the parity drive needs that and it also explains why the check is slow.

You need check filesystem on disk 4 It also appears that your parity drive is having continual resets, probably due to a flakey sata / power connection to it. Reseat / replace the cabline.

Post your diagnostics Flagging @ljm42

Never seen that issue. Try disabling Indexing with Windows

edit /var/lb/docker/unraid-autostart

It appears that on that old version and setting it to backup the cache drive instead of the appdata share results in the plugin deleting /mnt/user0 so that the restored copy of /mnt/user/ShareName (which you don't have) is an actual restoration with no extra files. Your best bet at this point is to invest in UFS Explorer, and recover the files via pulling the drive and tossing it into a Windows Box

What's this all about?

OTOH, unless every drive came up as unmountable when you swapped out the cache and then formatted them, I don't really see how this is possible. What are your settings for the Appdata Backup/Restore. Did you change anything when you restored? Did you ever run the Cleanup Appdata during this process?