inanepunk

Hi, I don't have an answer for you, but I may have a similar problem. perhaps you can see if we are experiencing the same thing? In my case every WebUI URL from the docker page is incorrect. So when I click on it I am taken to the wrong IP address (my server is x.x.x.12 every URL is x.x.x.x128). So as a result I get a generic error message (because no server is running at x.x.x.128) . if I then delete the 8 from the URL in address bar I am able to connect to my docker containers as expected. I have not worked out what is causing it as of yet.

Thanks for your reply @frank1940 ! i did try just copying the config directory in as you say, but i had the same problem. I suspect that my USB was on its way out when the back up was taken and that probably some files were corrupt in the backup. Anyway, parity check is running and its all looking good now. Yes, it the small USB did appear to overheat very quickly - I've used a regular sized USB drive for now, lets see if it lasts longer!

Ended up picking my way through the config file restoring individual files from my backup over the top of of a vanilla install until i got the config i needed (disk layouts, cache drive, shares and plug-ins). it was time consuming and frustrating, wouldn't recommend it.

My USB drive died without warning. It was a sandisk micro and lasted a whole 4 months. Fortunately i have a backup. Unfortunately when i recover my backup to a new USB device my server won't boot. If i do a vanilla install from the USB flash creator it will boot, but that is no good as its missing all the config. If i recover from my backup using the USB flash creator i'm unable to access the web console. I get the same problem if i try to do a manual recovery. How can I find any info as to why it isn't fully booting? What are my options in terms of recovering some of the configuration? Thanks!

I moved it to onboard SATA and changed the power cable. So far so good. but it hasnt been in very long, ill monitor over the next hour or so. I have notice that it appears to power down when not in use. is that normal for SSDs in UD?

working for me now - thank you!

Understood - i have attached it here. Thank you. tower-diagnostics-20190502-0910.zip

Apologies if this is the wrong place for this. I'm a long time lurker, but been actively using unraid for a few months now. Looking for some assistance/pointers with an issue i am having. Background I had a spare SSD which i added to my array and was using it as a transcode location for plex. This was before i realised that it wasn't a good idea to have SSDs in the array itself. I have since removed it from the array and have been trying to mount it using UD and present it to my containers. When i first mount the device in UD it all appears fine - i am able to format it and mount it successfully. I can successfully navigate to it in the terminal and do basic r/w test etc. all good so far. I then configure my container to be able to use it (mounted with rw:slave option) and restart the container, i can access the disk location through the containers terminal and the application. again all good. Problem After about an hour, the disk appears to spin down and is no longer available to the container or unraid. it is not possible to spin the drive back up, and the following is written to the disk log: Apr 30 11:16:16 Tower unassigned.devices: Successfully mounted '/dev/sdj1' on '/mnt/disks/transcode'. Apr 30 12:18:03 Tower kernel: sd 1:0:8:0: [sdj] tag#0 CDB: opcode=0x28 28 00 15 d5 43 38 00 00 08 00 Apr 30 12:18:04 Tower kernel: sd 1:0:8:0: [sdj] tag#0 CDB: opcode=0x28 28 00 15 d5 43 38 00 00 08 00 Apr 30 12:18:05 Tower kernel: sd 1:0:8:0: [sdj] tag#0 CDB: opcode=0x28 28 00 15 d5 43 38 00 00 08 00 Apr 30 12:18:33 Tower kernel: sd 1:0:8:0: [sdj] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Apr 30 12:18:33 Tower kernel: sd 1:0:8:0: [sdj] tag#0 Sense Key : 0x2 [current] Apr 30 12:18:33 Tower kernel: sd 1:0:8:0: [sdj] tag#0 ASC=0x4 ASCQ=0x2 Apr 30 12:18:33 Tower kernel: sd 1:0:8:0: [sdj] tag#0 CDB: opcode=0x28 28 00 15 d5 43 38 00 00 08 00 Apr 30 12:18:33 Tower kernel: print_req_error: I/O error, dev sdj, sector 366297912 Apr 30 12:18:33 Tower kernel: sd 1:0:8:0: [sdj] killing request Apr 30 12:18:33 Tower kernel: sd 1:0:8:0: [sdj] UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 Apr 30 12:18:33 Tower kernel: sd 1:0:8:0: [sdj] CDB: opcode=0x35 35 00 00 00 00 00 00 00 00 00 Apr 30 12:18:33 Tower kernel: print_req_error: I/O error, dev sdj, sector 244198784 Apr 30 12:18:33 Tower kernel: XFS (sdj1): metadata I/O error in "xlog_iodone" at daddr 0xe8e2d40 len 64 error 5 Apr 30 12:18:33 Tower kernel: XFS (sdj1): xfs_do_force_shutdown(0x2) called from line 1250 of file fs/xfs/xfs_log.c. Return address = 0000000028f9350f Apr 30 12:18:33 Tower kernel: XFS (sdj1): Log I/O Error Detected. Shutting down filesystem Apr 30 12:18:33 Tower kernel: XFS (sdj1): Please umount the filesystem and rectify the problem(s) The only way to get the disk present again in the UD interface is to restart unraid. I do have the default spin down time set to 1 hour, but gather this doesn't affect UD disks (I have turned this off to double check and had the same results). The disk passes smart checks and doesn't have any errors, its not over heating (highest recorded temp is 33c). Appreciate if anyone can give me any pointers...