MichaelAnders

Ah, cool! For my analysis so I understand it: I can find "powerdown" in /usr/local/sbin/powerdown. File content: #!/bin/bash logger "/usr/local/sbin/powerdown has been deprecated" if [[ "$1" == "-r" ]]; then /sbin/reboot else /sbin/init 0 fi So basically "/sbin/init 0" is triggered, which in turns (by Linux itself) triggers "/etc/rc.d/rc.0" which then does all the magic right? Perfect!

Background: My Unraid server runs only when needed and I wake it up via WOL. A UPS powers Unraid server and several other hardware One hardware watches the UPS state and once power failure occurs it initiates SSH connections to other systems and requests them to shutdown Requirement: The Unraid server shall also be told to shutdown - but in a "clean" fashion as if was using the UI. Otherwise, the server will loose power and I'll have an "unclean shutdown" which is not cool and totally unneeded... Problem: No idea how to do that? It's clear that the "Shutdown" button on UI will "initiate" some code - which obviously triggers something in Unraid linux code. I could now spend time on figuring out how to log into my Unraid server using WGET etc., then simulate I am on the UI and pressing the "Shutdown" button to trigger that. But that's pretty stupid to do as the functionallity is available "somehow".

Not sure if we understand each other. What I mean is: I have one "disk" which is shown on the main page. This disk is however a (Adaptec hardware) RAID 0 disk - from 2 TB I get one 4 TB disk. Reason for doing this is: these old 2 TB disks are robust (can't say that from the current WD/Seagates) but slow, so RAID 0 makes sense. For this disk I could set the SMART controller type to 0,0,12 /dev/sdi. But that is just one disk. The other disk is 0,0,13 /dev/sdi. For such constellations, it would be nice if I could state how many real disks are in use for this disk (even mainboard onboard RAIDx would face the same issue) - and specify the SMART controller type individually - get all the SMART data for each disk - see the median temperature for the disks on main page

Hi, I'm cleaning up my Unraid 6.8.3 disks. All disks are formatted with XFS. "Moving" means: copy/overwrite file in other folder and if successful delete original file Moving files around using Dolphin via Docker, SMB via Windows, SMB via Linux shows the following behaviour for some files: The original file is moved to the target folder (overwrite questions is always answered with YES) Effect: The original file is visually deleted in the UI, the moved file shows up in the target folder in the UI The original file shows up a few seconds later in the UI of the target folder (maybe requiring a refresh) and it can even be opened 😳?! So the "deletion" did not work - or the file is somehow being resurrected by the OS/Unraid/... Moving the original file again and overwriting it in the target folder once more finally deletes the file No errors in dmesg - no idea where else to look... This is extremely annoying - I had to realize that I'm actually doing the clean up the 3rd time now for the same files (I never realized the move failed long long back)... considering I'm talking about moving 1,000 of files into many newly created folders this is really hell.

Thanks for the quick reply! But now you got me confused... The log is from the current state after rebooting and before mounting the disks (which I will now do and back up the disk to another PC). If the disk is fine then why is Unraid stating the disk is disabled? Shouldn't Unraid state "why" disk 8 (although "fine") is disabled? Maybe in some log (I didn't see anything)? If not, would be a great thing to see in the logs something like "disk 8 disabled due to XYZ", making it easier to narrow down the problem.

Hi all, I've been playing around all day with Unraid and creating some RAID0 drives for performance reasons. Now, just before I decided to - merge the last two disks - assign an existing disk as 2nd parity - allow a full rebuild I - luckily - ran unraid again to double check that all is good. But it's not... One of my drives states "device is disabled" - and I'm not sure why? I've also detached the disk from the RAID controller and plugged it into the mobo, didn't change anything. Attached are the diagnostics. HDD in question is Disk 8, sdb From what I can see: 1) SMART looks fine 2) the disk is present in dmesg 3) "dd if=/dev/sdb of=/dev/null" also shows the disk being accessed and I hear it as well Any ideas? tower-diagnostics-20200609-1610.zip

I guess you are refering to the Integrity of the files on the disks? That is just one of the two problems I see here. Plus, any server "can" reboot for some reason right? So if I wanted to attack such a system, I'd press the button, pull the USB stick, adjust it, reinsert it and let the user press the button again. He'll never know I did anything... Correct. Such "local" attacks are one attack vector. Using local and my above assumptions I get a security related CVSS rating of ~ 6.1, which is "medium". Still, if you look at other security updates which have been released e.g. by Microsoft, they also sometimes include local access to the system. Still the publish fixes for the vulnerabilities. And that is in my opinion way over the top. I don't want to fiddle around with my hardware as the vulnerabilities can be solved in software. That is an option, but takes a lot of development effort. That's why I suggest to rather just encrypt the attackable files on the USB disk which can be easily tampered with as a first step of reducing the attack vector. Of course it would be possible for Limetech to create a disk creator similar to what other Linux distros use, allowing the user to set up an encrypted (USB) boot disk which can then also automatically unlock all other disks. Not sure if that would work for Unraid due to the limitations which I believe exist regarding the USB stick & license key, but maybe I'll give it a shot to set up an encrypted USB boot disk which then boots Unraid without any possible tampering.

All my hard disks are encrypted. One reason for doing that is so that the content of the disks are protected - which also means that the file names etc. are also not known until the disks are unlocked. The only part that is not encrypted is the USB drive. Looking at the /boot/config/shares folder I can see all the shares which I created. While not disclosing the files, the "content" on the disks can be guessed based on the filename. That is considered an "Confidentiality" vulnerability (even if not a very critical one in this case). None the less, it is one. Renaming the shares to something like A, B, C ... beats the purpose of defining names at all and is therefore not helpful imho. And it doesn't prevent other issues, Additionally, these configuration files store information on the shares regarding the "security" levels. An attacker just needs to pull out the USB stick and change the shareSecurity from private to public, reinsert the USB stick and then has access to the share. That is considered an Integrity vulnerability which allows the attacker to delete/change/add (maybe illegal stuff) data on the encrypted share (even the flash disk allowing covering up any changes made) which could even get the user into a lot of trouble when user unlocks his disks and finds a surprise there... However, as the shares are not used (and therefore useless) until the disks are unlocked (scenario: the user has encrypted all disks), it would make perfect sense to store the configuration files of the shares in encrypted format instead of plain text as is done right now. Suggestion: Using the keyfile (which is created after the user has unlocked the disks) as the password for AES encryption/decryption of the filename and it's content is easily possible, preventing both attack vectors. The same applies to other data I suspect is being stored on the USB stick, e.g. "users" (config/shadow), log files (could be stored as encrypted ZIP files), and maybe more (maybe a wlan password?) I can't think of right now. Maybe everything in the config file??? The argument "but the attacker would need access to your system so this is not really a problem" is imho not valid. The issues should be fixed (and I cannot imagine this being very difficult to achieve from a code perspective). And also true is that this will not prevent someone from changing the unraid code itself to achieve the same goal - but that is a different technical league. The ultimate security would be available using USB disk encryption for Unraid so that the authentication (and unlocking) happens when the system starts, but that is a different technical league to accomplish as well in Unraid. And all this may sound paranoid, but since Snowden paranoia is now reality I guess So whatever can be done to increase security should be done imho.