Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

33 Good

About tr0910

  • Rank
    Advanced Member


  • Gender

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. You either have a MB USB port defective, a rogue app or script that is writing to the USB flash drive, or a bad USB thumb drive. Non of these things involves unRaid. The fact that you have replaced several makes me think it might be one of the first 2. Sent from my chisel, carved into granite
  2. I can still report this working well from USA to China. No VPN is used once the system is set up and running. It is all SSH from one server to another. An always on raspberry PI is used if you need to start a remote server via IPMI. I hope we get somebody to curate this topic an make it easier to implement. Thanks to @ken-ji for helping us all. Finally, it would be great if something like this could be available via the gui as plug and play someday.
  3. There sure is interest in a good write up of the snapshot feature. Command line is ok. What about snapshots of important data directories on the array? Is this the same? Sent from my chisel, carved into granite
  4. Your existing key is the only way to get your data back. As long as you didn't reformat the drive you should be ok Something does look wrong though. The disk should be showing already padlocked. Both your disks show unlocked. Are you sure you didn't select an encrypted disk to be parity? Which disk serial number was encrypted?
  5. Started with a duct-taped throw away old AMD PC with 1gb RAM back about 10 years ago, and today have several Xeon 2670 based systems with 128GB ram in 4U rackmounts. Things have changed for the better. In 10 years the only drama has been several HD failures rebuilt from parity, and numerous HD dropouts related to questionable SATA cabling and a bad power supply. With the server hardware in place now, the SATA dropouts are no longer an issue. HD failures continue to be contained very nicely and now the Docker and VM's mean that once in a while I can even stress a beefy server. ECC memory and dual redundant power supplies on the server hardware is a nice benefit, but honestly, the better quality of the server hardware means that nothing fails anymore.
  6. I see @bonienl already has Wireguard support linked to his huge dynamix thread with all his other plugins. I'll leave this here for now. http://lime-technology.com/forum/index.php?topic=36543.0
  7. Thanks to @bonienl @ljm42 @NAS and of course @limetech we now have wireguard implementation on unRaid. Talk about it here.
  8. Ok, seems like we need to set up a Wireguard thread for 6.8 to siphon off the comments from here. I'm sure @limetech wants this to only capture the issues with 6.8rc1 Creating one now....
  9. Looking forward to Wireguard comments. Thanks @limetech @bonienl@ljm42 @NAS for a new VPN option.
  10. I've never suspected this but do you have any proof of it happening? Sent from my chisel, carved into granite
  11. tr0910


    Once the beta is finished, can we expect a normal release of 6.7.3 ? Sent from my chisel, carved into granite
  12. I replaced the dual PSU in mine with a single standard atx quiet Platinum rated PSU. This made a huge difference in noise. A bit of work as it's not drop in. I never touched the fan wall as that would have only made a minor improvement. Regarding the low power CPU, don't waste your time on that. Especially if the low power version costs more. At idle they are about the same, they just don't have the headroom. Why pay more for slower. Your disks during parity checks are where most of the heat will come from Sent from my chisel, carved into granite
  13. What would we add to have it also grab LUKS headers from unassigned disks mounted? Correction, it seems to already do unassigned disks. Awesome...
  14. @dlandon I never meant to suggest you were responsible for this issue. At one time I heard that @limetech planned to integrate Unassigned Devices (UD) into the core product. Perhaps this has been pushed out. Heroes like yourself bear way too much burden from us greedy users. (please, just one more tiny change to UD.... LOL) Still the bottom line persists. As I said earlier, (more of us are using the product in ways that the original security design never intended) and this results in demands for tightening up the security of the core product. This is not a bad thing, but it does consume resources of our hero volunteers, and from Limetech. I was only wanting to raise this issue while we were all paying attention. I have been able to work with what we have for UD encryption. I admit that now I use UD for more than I used to, and this results in me passing encrypted UD disks between servers. Provided you accept the limitations, it works.
  15. unRaid has never been sold as a secure OS that should be exposed directly to the internet. However more and more of us are using the product in ways that the original security design never intended. I don't share the panic regarding plain text passwords in /root that has been discussed here recently, however now that we are all paying attention, let me explain something that is a larger concern. When unRaid introduced LUKS encrypted disks for the array, I immediately implemented on one server that could benefit from increased security. I have been running encrypted disks without problem since that time. This server also has a number of unassigned disks that are connected and disconnected from the server. Thanks to @dlandon we managed to get unassigned devices to support LUKS drives as well. But there is one huge problem. The unassigned devices require that all disks use the array LUKS password or keyfile. This is not good especially when we move disks from server to server. You can only use LUKS encrypted unassigned disks if the array already has at least one disk encrypted. And this password/keyfile must be the same on all servers where the disk is plugged into. This should be looked at if further enhancements are being made to the encrypted file system.