khager

@TRURL - thank you. Worked like a charm. Now I have an empty slot to mirror my cache drive and my OCD is satiated. I keep losing cache drives for some reason - maybe because I keep using my old disks that I pulled out of the array (?). I have two new WD Reds on order for mirroring cache this time so, hopefully, it'll last for a while. I don't post here very often (unRaid user & member since 2009) so I just have to say - again - I love unRaid. Especially the later versions. Thanks to everyone for a great product.

I read the whole thread and I just want to double-triple-quadruple check that I'm doing this the right way. I'm running v6.8.2. I have 1 parity drive and did have 7 data drives. Disk5 was old and starting to get errors. I have enough space that I can just remove that disk from the array (and it'll free up a slot for me to be able to mirror my Cache drive). So far I have: - Moved all data off of disk5 onto other disks - Used the "shrink array" instructions in the wiki to unassign disk5 - Parity check is currently running ("Parity is valid" was NOT checked) When that's done I want to: - shut down the server - physically remove what was disk5 from the server and throw it away - physically move disk6 to the slot previously occupied by disk5 - physically move disk7 to the slot previously occupied by disk6 What will I see when I bring it back up after physically moving those 2 drives to different SATA cables (and removing the one that's now unassigned)? Can I just do a New Config and reassign the drives that were "disk6" and "disk7 to "disk5" and "disk6"? When I restart the array after this New Config, should I indicate parity is valid or not? Thanks, Kyle

Well...now restores are working. I do not know what changed. Maybe some folder permissions, maybe I'm crazy. In any case, restores are working like they should and I no longer care why they didn't before. I was able to restore a photograph library from 2016 that got corrupted some time between Jan and May this year. I'm happier about that than I am curious why the previous restore attempts didn't work. So, in the words of the late, great Roseanne Roseannadanna.... .... ...never mind...

I've tried restoring to just about anywhere the interface will let me. Example: the container path of /storage/... maps to the host path of /mnt/user. This allows me to backup from anywhere on the Unraid array. I've tried restoring to several different shares in that path. I've also tried to restore to /config in the container - I log into the container but there are no restored files in that path. I've also tried restoring to "original location" but that yielded the same results. restore_tool_app.log contains these lines for the most recent attempt: INFO : 2020/05/22 06:28:07.715174 restore_tool.go:99: RestoreTool: Start INFO : 2020/05/22 06:28:07.763725 restore_tool.go:100: Runtime directory: /tmp/com.code42.restore/app INFO : 2020/05/22 06:29:47.520276 restore_tool.go:472: Received terminate gracefully message INFO : 2020/05/22 06:29:47.520737 restore_tool.go:474: Received keep-alive message INFO : 2020/05/22 06:29:47.526648 restore_tool.go:197: Error received reading size (possibly end-of-file). err=EOF INFO : 2020/05/22 06:29:48.525365 restore_tool.go:171: RestoreTool: Graceful Exit Tail of history.log.0 contains: I 05/22/20 06:28AM Starting restore from CrashPlan PRO Online: 3,445 files (135.70MB) I 05/22/20 06:28AM Restoring files to /config I 05/22/20 06:29AM Restore from CrashPlan PRO Online completed: 3,445 files restored @ 52.4Mbps The last line in restore_files.log.0 contains: 05/22/20 06:29AM 41 Restore from CrashPlan PRO Online completed: 3,445 files restored @ 52.4Mbps Tail of service.log.0 contains: [05.22.20 06:29:48.318 INFO ub-BackupMgr om.backup42.service.AppLogWriter] WRITE app.log in 499ms [05.22.20 06:29:48.350 INFO ub-BackupMgr 42.service.history.HistoryLogger] HISTORY:: Restore from CrashPlan PRO Online completed: 3,445 files restored @ 52.4Mbps Tail of ui.log contains (note times in this log are UTC and I'm in CDT so UTC -5 for local time): 2020-05-22T11:28:07.392Z - info Restore: Successfully created restore job 2020-05-22T11:28:07.688Z - info: Launching process: (20016) /usr/local/crashplan/bin/restore-tool -userName=app -logDir=/config/.code42/log /tmp/restore-pipe-955293482861554839-request /tmp/restore-pipe-955293482861554839-response 2020-05-22T11:29:48.532Z - info: Process exited cleanly with code 0 and signal null A restore takes as long as you would expect, counting up the amount of data it's restoring, etc. The log files even show the throughput figures. it's just not putting the restored files anywhere I can find.

I am unable to restore files from my CrashPlan backup. I have the Access Mode set to Read/Write. When I restore, CrashPlan goes through the motions of downloading - takes several minutes to get 4GB down, etc. But then no files are ever restored. restore_files.log lists all the files being restored and ends with "Restore from CrashPlan PRO Online completed: 1,463 files restored @ 49.3Mbps" - but no files were restored. I've tried restoring to the original location & a different location. I've tried setting to "overwrite" and "rename" but still nothing. Any ideas?

the "oneFilePanel" entry in .cloudcmd.json is set to "false" I have deleted the docker and cleaned up the leftover file in appdata. I'll try and install again and see if it behaves.

I love this tool so far - been using it for about a week while I reorganize my shares. One problem: I can no longer see 2 file panels - just one (larger/full-width) panel). I don't know what i did to turn it off but if I show the config pop-up, "One File Panel" is NOT checked. I tried clicking it on and back off but no good. I tried stopping and restarting the docker - still only one file panel. How do I get the 2-file-panel view back on? Thanks,

Those settings are very similar to the several SMTP servers I've tried. In my case, it times out without getting any response back from the SMTP server. My thinking is that the only way I would get "No reply" / timeout error is if I got the address or port wrong. Other incorrect settings would likely produce a different error - is this a correct assumption?

I haven't been on this forum in several years - a testimate to unraid reliability and the online help I get here. I'd like to setup email notifications but can't get past the setup. Every time I try to test the SMTP settings, I always get "No reply from email server". I have access to several SMTP servers and I get this reply every time. It's not even trying to log in. I've searched and searched the forum with no luck - this has to be something simple I've overlooked. A router or firewall setting? Some other setting in unraid? It's just not that hard to contact an SMTP server - I must be paying my stupid-tax. Any help? Edit: I'm running 6.2.4

Oh well. At this point I think I'll just wait for my new disks to arrive, preclear on that controller, bring one into the array and see what happens. I've already prepared a couple old drives and that worked fine but I've decided to wait on the new disks before bringing one into the array. I'll post back here on that once I have some info.

OK - sorry for the delay but tonight was the first time I was able to work on this. Those values in the motherboard BIOS were already set to "Yes". I also tried another PCIE slot. I also added the jumpers to the motherboard I referenced (i.e., "connect the PCIE slots to the System Management Bus". Nothing helped - no change with any combination "Yes" flags, slots, or jumpers. I cannot access the RAID card BIOS / I don't get any messages on the screen that look like the ones posted by johnnie.black. Any other suggestions?

@BobPheonix, Sorry for the late reply. I just got back home (10:00 p.m. here) and won't be able to look at this tonight but I wanted to say, "Thank you." That's what was needing. I found what you referenced in the manual (under "PCI/PnP Configuration" - I remember seeing that area in the motherboard BIOS). I obviously didn't recognize that when I saw it before. I'm a software guy and couldn't tell you the difference between a BIOS, an OPROM, or a DUI. For me to recognize that, it probably would have to be labeled, "Hey - if your RAID card doesn't show up, turn this on." By the way, those slot numbers listed cover both PCI and PCIE slots so apparently that covers both types. Thanks for the kick in the right direction. I'll try this out when I can and post back here. @johnnie, That's what I was thinking - thanks for confirming. "OPROM" - that's what I look for - I didn't know that.

Ok. I see how my post was confusing. During boot, only the drives connected to the motherboard are listed (they were always listed even before adding the RAID card). Drives connected to the RAID card are not displayed. During boot, there is only one indication that a RAID card exists: it is listed as occupying PCIE slot 6. I don't get any prompts or any other message from the RAID BIOS. Should i? I have poured over the motherboard BIOS settings and cannot find anything that looks like it would limit the BIOS from a PCIE card from displaying or being interacted with. That's why I brought up the jumpers in the previous post. I'm wondering if those jumpers are preventing this - but I'm a little scared to add them and was asking if anyone could interpret their meaning for me based on what I posted from the motherboard manual. I've attached 3 pictures of the monitor during boot. Maybe there's something I'm missing. I'll also try another slot. On a good note, the RAID card seems to be working but I have not brought those drives into the array yet. Only preclear and SMART tests and such. I want to make sure it's working before adding one of the drives on the RAID card to the array.

...but it's not. That's the problem I'm having. The RAID BIOS does not display anything during boot up. I can't <ctrl>-M to access it either

Just wondering if anyone has any thoughts on this. Right now, I can't access the RAID BIOS and I can't tell the firmware version or if INT 13 is disabled - but it seems to be working okay so I'm a little anxious about messing with a good thing. Any ideas if trying out these jumpers will cause irreparable harm?

That's what I was expecting since this is the behavior I have experienced on other machines that had RAID cards in them. I've tried pressing <ctrl>-M during the boot process but that was ignored. My motherboard is Super Micro C2SEA (2010 vintage) and I've been through all the settings in its bios but didn't find anything that hinted toward displaying ROM messages. However, Your post got me to look at the motherboard manual and I found 2 jumpers mentioned that are described as follows: Jumpers JI2 C1/JI2 C2 allow you to connect PCI/PCI-Exp. Slots to the System Management Bus. The default setting is open to disable the connection. These 2 jumpers are currently open so I'm wondering if closing those connections will "connect" the RAID card to the "System Management Bus" (I have no idea what that means). Any thoughts?

I just installed a Super Micro AOC-SASLPMV8 SATA controller (all the SATA ports on my motherboard are full) I am not able to get to the controller BIOS. What's the trick? I read that you need to press <ctrl>-m on the screen that lists the drive serial numbers but that didn't do anything (I tried several times). There is no prompt on any of the boot-up screens that indicate I can enter this BIOS. But - the card is there and the OS found it. I have 3 (unassigned) drives plugged into it and they appear on the web interface - I'm running preclear on one of them right now. So, obviously the card is there but why can't I get to the BIOS during boot-up? I'm probably missing something simple - just need a little advice. Thanks.

That's how HP/Compaq builds them. "C" channel makes the 4 posts. Then the little angle with the properly-space holes is screwed to the channel. The critical part is that they're properly spaced, (near) perfectly parallel and making sure there's no wobble after it's put together (solid top & bottom frames welded to the 4 upright channels).

There's only one serial port header on this motherboard (and no built-in serial ports on the back).

starcat, I was thinking the same thing. I'll pull that out and test it next time I have the box open. I'll post the results here. Just for kicks, can someone who has the serial port working post the address & IRQ settings for that port? I haven't heard anywhere that it matters but that would rule out another variable. Thanks, Kyle

Just to be sure (in case you know the answer to this). I have a Supermicro C2SEA mobo (American Megatrends BIOS). In the I/O section, there's a setting for the serial port. There are 4 address/IRQ options plus one that "Disabled". I tried 2 of the address/IRQ combinations (i.e. that setting was not set to "Disabled"). There's not another place in the BIOS that would disable the serial port, is there?

That's not a dumb question. That's just like something I would do. But I did check that. I even tried a few different address/irq settings to no avail.

Well - it's not the cable or the UPS. Both work fine on my Ubuntu server. I've been round and round with this. Double checked everything, tried different interrupts on the serial port, etc. About the only thing it can be at this point is either the port itself on the mobo or that doodad that plugs into the mobo and converts it to a DB9 port on the back. I never could get it to work with my last mobo and I'm using the same doodad so that's probably the culprit but I don't have any way to really test it. For now, I'm sharing the UPS with my Ubuntu server / unRAID server as a slave (ethernet connection). I just manually configured apcupsd.conf and saved a copy on the flash drive which I copy back over after installing during boot up. I would really prefer unRAID to be the master so the boxes that mount shares from it would shutdown first. At least what I have now is better than just pulling the plug. I've got batteries on order for another UPS with a USB port. When those come in I'll try again with unRAID as the master using a USB port.

Since /dev/ttyS0 exists, I can assume Linux "sees" that as a serial port during bootup, right? If so then I guess that takes me back to the cable or possible the UPS itself. I wish there was something I could do to test the port itself to make sure. I have two of those cables that came with two different UPS's. I'm not using one of them so I'll try switching it out and see what happens. What about the port speed? Do I need to do something to set that properly (and if so how and what speed should it be)? Thanks, Kyle

hhhmmmm - OK now I'm stretching the limits of my Linux knowledge. My motherboard only has one serial header so there's no room for confusion on the hardware side. Does "ttyS0" map to a specific interrupt or is it just always the first serial port found? Or is there some other method to ensure that "ttyS0" maps to that DB9 on the back of my machine (which connects to the serial header on my mobo)?