tr0910

I warn you, there is no "SSH for Dummies..." Sent from my chisel, carved into granite

Your welcome. @ken-ji to the rescue Sent from my chisel, carved into granite

A thorough understanding of ssh keys is required to fully understand what is wrong. Trouble is all of us just hacked ours together. We all had the same troubles you are having. Then suddenly it just worked. And we are not really sure why. @ken-ji is the most knowledgeable and helped most of us get going. Be patient, there really is gold at the end of this rainbow

As of right now it seems that the evidence has vanished like a puff of smoke. Some 3 letter agency has the evidence all hidden in a warehouse?

Again the answer is maybe. Check the thread out. It links to good external analysis. So far, documented proof is lacking. Don't worry about your Supermicro builds for now.

You'll find it in the status of encryption thread. It's done from the command line, so no you won't see it in the web GUI. And the good news is that it doesn't result in any data loss.

Yeah, there is a bit of black magic here that secures the rsync over ssh. Once properly applied, it just works. This thread contains detours that frustrate folks before getting things working completely. Sent from my ONEPLUS A3010 using Tapatalk

Part of me wonders if this is political. First the government is just releasing a huge cloud computing bid. Second Google just announced they will not bid as it conflicts with their corporate values..(eyeroll). Third, a whole crapload of e5 2670 xeons hit the market at extremely depressed pricing about 2 yrs ago along with matching ecc memory but there were no motherboards. Perhaps the motherboards were compromised? My take is that there is enough truth here to use this as a political weapon, and maybe affect the bidding process for government cloud computing. For some unknown reason, Supermicro is the sacrificial lamb here. And Amazon by being fingered as a victim will have a tougher time assuring everyone they should automatically win the bid.

I have often wondered about that. I have 6 of the e5-2670 and a boatload of RAM. Now wished I had purchased more at $70. Prices have rebounded significantly. I'm surprised Facebook and Google aren't also listed as being victims.

Your server RAM will be used as write cache. How much RAM do you have?? I assume this is with turbo write turned on? Are you using 10gbit networking between the source of the file and the dest on the server?

Yes, you have to careful with older server hardware, but I have some ancient TAMS 24 bay servers with very old intel and AMD cpus that suck power like crazy, but since they have ipmi, they can be shut off and only be turned on via a VPN protected IPMI script call, and then they accept backups just fine. After they are done they are turned off via IPMI. I also have some dual Xeon 2670 based hardware that I use 24x7 and power use and noise are very well controlled in an Intel P4000 chassis. Since 2670 days, the advances to Intel power and performance has relatively pathetic. Sure you need to be careful, but Intel 2670 gen 1 is good stuff and recent enough that you are OK. Just be aware of Spectre and Meltdown issues and keep your patches current.

(Assuming there isn't anything important on that drive. If there is do a backup first) The only file that needs saving from the old thumb drive is the pro.key or plus.key file in your config folder. Then you can either just copy you existing 6.5.3 flash drive over top of the old thumb drive, or use the Limetech create new USB tool. Once done, place that key file you saved back in the config folder, replacing any other one copied across. The pro.key file is linked to the USB guid and is what tells unRaid you have a valid license for that USB stick.

To echo what @jonathanm says, the server can have trouble shutting down when seemingly trivial things are running. Even something as simple as an open command prompt window sitting at /mnt will stop a safe shutdown. These things have gotten a lot better, but always shutting unRaid down cleanly is still a work in progress. Doing as suggested, you can see if it really did stop the array. If it stops the array successfully, there should be no issue rebooting cleanly.

Yeah, I agree, there are some things being held close to the chest. It is being named 6.6 and dressed up all pretty for a reason.

Google didn't clue me in that this was known and already reported. Thanks for creating a ticket.

Any solution to this yet? Sent from my ONEPLUS A3010 using Tapatalk

Same error here: @bonienl and here

This also happens updating one of my other VMs from VNC to GPU passthrough. This is the first time I have attempted GPU passthrough on this system. But all the IOMMU groups look good. Is this just an issue with saving the template in unRaid? GPU is XFX Radeon HD 5000/6000/7350/8350 series

Using 6.6rc1 I create a new Win10vm, with VNC graphics and start it up successfully. I then edit the VM passing though the GPU and the keyboard and mouse and press update and booom.... VM creation error internal error: Cannot parse <address> 'function' attribute drchina1-diagnostics-20180905-1507.zip

@jonp is in full tease mode now.

Don't panic. This file is stored in RAM and disappears if the server is rebooted. It is only there for convenience, allowing you to stop the array and restart without requiring you to always key in the pass phrase. There is discussion to make this optional in some way to further harden the OS for those wanting extra security. For now you can just press that button to delete that file.

Any file is good so your dinner photo is fine. unRaid will use the first 8mb of the file and ignore the rest (need to confirm 8mb part), so it could even be a huge file. I like your dinner photo but Ssh keygen might be more safe from a crypto standpoint.

I'm fed up with slow internet in the evening. I need to figure what is wrong and hope some of the networking experts can point me in the right direction. The connection is fiber 200/20 and at 8am in the morning, I get speedtest results of 307/36 with a 2ms ping. This is awesome, but by 8pm, the internet gets glacial. You see it especially bad when just normal web browsing. Now the connection seems to be able to download fast even in the evening. I can torrent down a Linux distro without noticing the lack of speed in the evening. But, normal browsing is painful in the evening. Rsync over SSH really shows the problem big time. If you graph download speeds of rsync over SSH you will get 5 megabyte/sec sustained transfer rates for zip files over 100mb in the morning. But by evening the rsync speed will drop to sustained rates of less than 56 kilobytes/sec. (this is rsync from China to a server in USA) How can I narrow down what the real problem is? (I am behind CGNAT on China Telecom, and since the provided modem/router is limited, I have my own router, a Netgear 6300 running DD-WRT. So I am double NATTED. I have tried Google DNS, but presently I have my router set to 0.0.0.0 so I use the default DNS provided by China Telecom)

Yes, this is exactly what I have run into with RDP. It's good, but not perfect. Totally depends on your expectations. If you want buttery smooth, you need to do pass through graphics (dedicated or igpu) and run USB and HDMI cables directly to your unRaid box. I am living with the RDP issues as for me direct cabling USB and HDMI are a non starter. I haven't found any remote solutions better than RDP.

This can happen with connections via Microsoft RDP sometimes. Do you get the same results via an RDP connection? Agreed, direct attached to the server should be buttery smooth. Sorry can't help with igpu.