Xaero

It does prevent compromising the entire array by discovering the key to one disk. If they implemented a system like this, they obviously would need to use a cipher system to generate the keys. This cipher system could need to have a "recovery" mode where if you are able to provide the full set of data it would be able to provide you with a luks keyfile to recover the data from the disk. This wouldn't break compatibility with existing luks systems, but would prevent an attacker from compromising the entire array if a single key is somehow exposed.

I wholely agree that you cannot fix stupid. But you can implement things in a way that take stupidity into consideration. This specific instance is capable of being mitigated by implementation. If you can implement mitigation you should.

Aside from you actually being correct, for many reasons, this keyfile is created so that you don't have to type your password in for every single LUKS disk in your array. Ideally, a few things should change with this part of the system. Allow me to point out an assumed security that is incorrect from people in the thread thus far: "It's in /root, so it's only available to the root user" - this is wrong for a couple of reasons; for one, this relies on no docker's being configured in such a way that they cannot see "/root" as any docker that uses a root account would also have access to this file. Furthermore, any bootable distribution, or hypervisor would also have access to this file (though it is detroyed every shutdown) Furthermore, the file is both plaintext, and stored in memory. Anything that manages to gain access to memory (We have several major vulnerabilities right now that affect different hardware and software implementations that allow access to the memory map, even to protected regions) can see this password. All of this assumes that simple privilege escalation attacks aren't viable (which they have been, in recent times, even.) In 2019, the only time a key should be plaintext is at the moment it is used. After that the variable it is contained in should be overwritten and destroyed. We must overwrite it because the kernel will simply mark that region "free" rather than writing 0's to it. Sure, it takes microseconds for it to be overwritten after being marked free on a system that has high memory utilization, but that's time it's available. We want to destroy the variable so there is no reference to it to make it identifiable after we use it. Furthermore, while it *is* convenient to have a single password for all of the disks - this is not ideal. Ideally (Imho) Unraid should generate a salted and hashed key from the user-defined luks password for each drive. You have two sources of unique data for each disk: The unraid license key, and the disk serial number. Using the license key ensures that no two unraid users can end up with the same salted key - even if they choose the same password and somehow have two disks with the same serial number. These salted keys should be generated based on the user's input and each disk should have its own unique key to mount it. This greatly increases the security of the system against brute force attacks.

I think there's a substantial computational advantage showing its face here. 6400 is 80^2 (power of two advantage for computing is strong) 3200 and 6400 - evenly divisible, exactly one-half - again, whole integers with no floating point precision, and it's exactly half - meaning the CPU can take shortcuts. I'm not 100% certain how the stripe size and window size interact, but those two mathematical advantages compared to the rest of the table could make a massive difference on a lower powered CPU.

I am partially colorblind. I have difficulty with similar shades (such as more green blues, next to greens, or more blue greens next to blues.) The default Web Console color scheme makes reading the output of ls almost impossible for me: I either have to increase the font size to a point that productivity is hindered drastically, or strain my eyes to make out the letters against that background. A high contrast option would be great. Or, even better, the option to select common themes like "Solarized" et al would be great. Perhaps even, the ability to add shell color profiles for the web console. For now I use KiTTY when I can - and I've added a color profile to ~/.bash_profile via my previously suggested "persistent root" modification. Also, worth mentioning here: https://github.com/Mayccoll/Gogh Gogh has a very extensive set of friendly, aesthetically pleasing, and well-contrasting color profiles ready-to-go. Edit: Also worth noting that currently the web terminal doesn't source ~/.bashrc or ~/.bash_profile, and this results in the colors being "hardcoded" (source ~/.bashrc to the rescue) Edit2: Additionally, the font is hard coded. If we are fixing the web terminal to be a capable, customizable platform - this would also be high on the list of things to just do.

SCSI Host Controllers and Connected Drives -------------------------------------------------- [0] scsi0 usb-storage [0:0:0:0] flash sda 62.7GB Extreme [1] scsi1 megaraid_sas MegaRAID SAS 2008 [Falcon] [1:0:11:0] disk13 sdb 8.00TB WDC WD80EFAX-68L [1:0:12:0] disk5 sdc 8.00TB WDC WD80EFAX-68L [1:0:13:0] disk7 sdd 8.00TB WDC WD80EFAX-68L [1:0:14:0] disk2 sde 8.00TB WDC WD80EFAX-68L [1:0:15:0] disk3 sdf 8.00TB WDC WD80EFAX-68L [1:0:16:0] disk4 sdg 8.00TB WDC WD80EFAX-68L [1:0:17:0] disk10 sdh 8.00TB WDC WD80EFAX-68L [1:0:18:0] disk21 sdi 8.00TB WDC WD80EFAX-68L [1:0:19:0] disk8 sdj 8.00TB WDC WD80EFAX-68L [1:0:20:0] disk12 sdk 8.00TB WDC WD80EFAX-68L [1:0:21:0] disk11 sdl 8.00TB WDC WD80EFAX-68L [1:0:22:0] disk15 sdm 8.00TB WDC WD80EFAX-68L [1:0:23:0] disk16 sdn 8.00TB WDC WD80EFAX-68L [1:0:24:0] disk19 sdo 8.00TB WDC WD80EFAX-68L [1:0:25:0] disk22 sdp 8.00TB WDC WD80EMAZ-00W [1:0:26:0] disk17 sdq 8.00TB WDC WD80EFAX-68L [1:0:27:0] disk18 sdr 8.00TB WDC WD80EFAX-68L [1:0:28:0] disk20 sds 8.00TB WDC WD80EFAX-68L [1:0:29:0] disk6 sdt 8.00TB WDC WD80EFAX-68L [1:0:30:0] disk9 sdu 8.00TB WDC WD80EFAX-68L [1:0:31:0] disk14 sdv 8.00TB WDC WD80EFAX-68L [1:0:32:0] disk1 sdw 8.00TB WDC WD80EFAX-68L [1:0:33:0] parity2 sdx 8.00TB WDC WD80EMAZ-00W [1:0:34:0] parity sdy 8.00TB WDC WD80EMAZ-00W [N0] scsiN0 nvme0 NVMe [N:0:1:1] cache nvme0n1 1.02TB INTEL SSDPEKNW01 [N1] scsiN1 nvme1 NVMe [N:1:1:1] cache2 nvme1n1 1.02TB INTEL SSDPEKNW01 Results from B3 look good!

It looks like his nvme drives have a 5th column. Not sure if thats the cause or not

I'm not sure if this will work; awk '{ if ($3 == "") print "Column 3 is empty for " NR }' This should print Colum 3 is empty for # where # is the row number. awk 'BEGIN { FS = OFS = "\t" } { for(i=1; i<=NF; i++) if($i ~ /^ *$/) $i = 0 }; 1' This may also work to replace empty columns fields with "0" but is a copy paste from a different application

The megaraid disks don't show up still, not sure what's causing that. SCSI Host Controllers and Connected Drives -------------------------------------------------- [0] scsi0 usb-storage [0:0:0:0] flash sda 62.7GB Extreme [1] scsi1 megaraid_sas MegaRAID SAS 2008 [Falcon] [N0] scsiN0 nvme0 NVMe [N:0:1:1] cache nvme0n1 1.02TB INTEL SSDPEKNW01 [N1] scsiN1 nvme1 NVMe [N:1:1:1] cache2 nvme1n1 1.02TB INTEL SSDPEKNW01 *** END OF REPORT *** Everything else looks good.

Don't worry, I'm sure some obnoxious niche thing with my server will cause a hiccup.

sort -n -t: -k3 I believe should handle this. You may need to strip the [ and ], so it'd be sed -e "s/[\[,\]]//g" | sort -n -t: -k3 Or something along those lines. I don't have a terminal accessible to test atm. To explain: -n sort numerals -t: change change delimiter to ":" -k3 sort by column 3. EDIT: forgot the -n flag above. EDIT 2: It's also entirely possible that the disk order not line up to the port numbers.

rdevName.0=sdy rdevName.1=sdw rdevName.2=sde rdevName.3=sdf rdevName.4=sdg rdevName.5=sdc rdevName.6=sdt rdevName.7=sdd rdevName.8=sdj rdevName.9=sdu rdevName.10=sdh rdevName.11=sdl rdevName.12=sdk rdevName.13=sdb rdevName.14=sdv rdevName.15=sdm rdevName.16=sdn rdevName.17=sdq rdevName.18=sdr rdevName.19=sdo rdevName.20=sds rdevName.21=sdi rdevName.22=sdp As you can see - my disks are actually numbered from 0 as far as unraid is concerned. I believe that's the host addresses starting at 11 - and that makes sense from a physical perspective as address 1 is the controller itself, addresses 2-9 are the links to the port expander, address 9 is the port expander itself (shown as "enclosu" in the report) and then address 11 is the first disk device. As you can see - they are actually numbered starting at zero as far as the md array for unraid is concerned. And yeah I suggest multi-dimensional arrays specifically because it nullifies issues like this, as instead of relying on indices and array sizes, we rely on "for each object" logic. Which will return in the order it was input, regardless of whether or not everything is incremental.

Unraid 6.x Tunables Tester v4.1 BETA 1 by Pauven Tunables Report produced Sun Aug 11 20:25:03 MDT 2019 Run on server: BlackHole Short Parity Sync Test Current Values: md_num_stripes=5920, md_sync_window=2664, md_sync_thresh=2000 Global nr_requests=128 Disk Specific nr_requests Values: sdy=128, sdw=128, sde=128, sdf=128, sdg=128, sdc=128, sdt=128, sdd=128, sdj=128, sdu=128, sdh=128, sdl=128, sdk=128, sdb=128, sdv=128, sdm=128, sdn=128, sdq=128, sdr=128, sdo=128, sds=128, sdi=128, sdp=128, sdx=128, --- INITIAL BASELINE TEST OF CURRENT VALUES (1 Sample Point @ 10sec Duration)--- Tst | RAM | stri | win | req | thresh | MB/s ---------------------------------------------- 1 | 569 | 5920 | 2664 | 128 | 2000 | 53.4 --- BASELINE TEST OF UNRAID DEFAULT VALUES (1 Sample Point @ 10sec Duration)--- Tst | RAM | stri | win | req | thresh | MB/s ---------------------------------------------- 1 | 123 | 1280 | 384 | 128 | 192 | 55.0 --- TEST PASS 1 (2 Min - 12 Sample Points @ 10sec Duration) --- Tst | RAM | stri | win | req | thresh | MB/s | thresh | MB/s | thresh | MB/s -------------------------------------------------------------------------------- 1 | 73 | 768 | 384 | 128 | 376 | 58.4 | 320 | 50.9 | 192 | 53.9 2 | 147 | 1536 | 768 | 128 | 760 | 61.3 | 704 | 61.8 | 384 | 57.8 3 | 295 | 3072 | 1536 | 128 | 1528 | 65.1 | 1472 | 64.8 | 768 | 63.4 4 | 591 | 6144 | 3072 | 128 | 3064 | 66.0 | 3008 | 66.0 | 1536 | 66.1 --- TEST PASS 1_HIGH (30 Sec - 3 Sample Points @ 10sec Duration)--- Tst | RAM | stri | win | req | thresh | MB/s | thresh | MB/s | thresh | MB/s -------------------------------------------------------------------------------- 1 |1182 |12288 | 6144 | 128 | 6136 | 65.8 | 6080 | 65.6 | 3072 | 65.0 --- END OF SHORT AUTO TEST FOR DETERMINING IF YOU SHOULD RUN THE REAL TEST --- If the speeds changed with different values you should run a NORMAL/LONG test. If speeds didn't change then adjusting Tunables likely won't help your system. Completed: 0 Hrs 3 Min 30 Sec. NOTE: Use the smallest set of values that produce good results. Larger values increase server memory use, and may cause stability issues with Unraid, especially if you have any add-ons or plug-ins installed. System Info: BlackHole Unraid version 6.7.2 md_num_stripes=5920 md_sync_window=2664 md_sync_thresh=2000 nr_requests=128 (Global Setting) sbNumDisks=24 CPU: Genuine Intel(R) CPU @ 2.00GHz RAM: System Memory System Memory System Memory System Memory Outputting free low memory information... total used free shared buff/cache available Mem: 49371152 9959400 37455020 1486356 1956732 37404184 Low: 49371152 11916132 37455020 High: 0 0 0 Swap: 0 0 0 SCSI Host Controllers and Connected Drives -------------------------------------------------- [0] scsi0 usb-storage - parity sdy WDC WD80EMAZ-00W [1] scsi1 megaraid_sas - MegaRAID SAS 2008 [Falcon] [N0] scsiN0 nvme0 - NVMe parity sdy WDC WD80EMAZ-00W [N1] scsiN1 nvme1 - NVMe parity sdy WDC WD80EMAZ-00W *** END OF REPORT *** lsscsi -st: root@BlackHole:/tmp# lsscsi -st [0:0:0:0] disk usb:3-9:1.0 /dev/sda 62.7GB [1:0:10:0] enclosu - - [1:0:11:0] disk /dev/sdb 8.00TB [1:0:12:0] disk /dev/sdc 8.00TB [1:0:13:0] disk /dev/sdd 8.00TB [1:0:14:0] disk /dev/sde 8.00TB [1:0:15:0] disk /dev/sdf 8.00TB [1:0:16:0] disk /dev/sdg 8.00TB [1:0:17:0] disk /dev/sdh 8.00TB [1:0:18:0] disk /dev/sdi 8.00TB [1:0:19:0] disk /dev/sdj 8.00TB [1:0:20:0] disk /dev/sdk 8.00TB [1:0:21:0] disk /dev/sdl 8.00TB [1:0:22:0] disk /dev/sdm 8.00TB [1:0:23:0] disk /dev/sdn 8.00TB [1:0:24:0] disk /dev/sdo 8.00TB [1:0:25:0] disk /dev/sdp 8.00TB [1:0:26:0] disk /dev/sdq 8.00TB [1:0:27:0] disk /dev/sdr 8.00TB [1:0:28:0] disk /dev/sds 8.00TB [1:0:29:0] disk /dev/sdt 8.00TB [1:0:30:0] disk /dev/sdu 8.00TB [1:0:31:0] disk /dev/sdv 8.00TB [1:0:32:0] disk /dev/sdw 8.00TB [1:0:33:0] disk /dev/sdx 8.00TB [1:0:34:0] disk /dev/sdy 8.00TB [N:0:1:1] disk pcie 0x8086:0x390d /dev/nvme0n1 1.02TB [N:1:1:1] disk pcie 0x8086:0x390d /dev/nvme1n1 1.02TB lshw -C storage: root@BlackHole:/tmp# lshw -c Storage *-storage description: RAID bus controller product: MegaRAID SAS 2008 [Falcon] vendor: Broadcom / LSI physical id: 0 bus info: pci@0000:01:00.0 logical name: scsi1 version: 03 width: 64 bits clock: 33MHz capabilities: storage pm pciexpress vpd msi msix bus_master cap_list rom configuration: driver=megaraid_sas latency=0 resources: irq:24 ioport:6000(size=256) memory:c7560000-c7563fff memory:c7500000-c753ffff memory:c7540000-c755ffff *-storage description: Non-Volatile memory controller product: SSDPEKNW020T8 [660p, 2TB] vendor: Intel Corporation physical id: 0 bus info: pci@0000:03:00.0 version: 03 width: 64 bits clock: 33MHz capabilities: storage pm msi pciexpress msix nvm_express bus_master cap_list configuration: driver=nvme latency=0 resources: irq:36 memory:c7400000-c7403fff *-storage description: Non-Volatile memory controller product: SSDPEKNW020T8 [660p, 2TB] vendor: Intel Corporation physical id: 0 bus info: pci@0000:04:00.0 version: 03 width: 64 bits clock: 33MHz capabilities: storage pm msi pciexpress msix nvm_express bus_master cap_list configuration: driver=nvme latency=0 resources: irq:26 memory:c7300000-c7303fff *-scsi physical id: a1 bus info: usb@3:9 logical name: scsi0 capabilities: emulated Hope this is at least helpful. Should be able to get my computer set back up this week, finally. Also, I didn't expect my system to work out the gate. The NVME disks at least show up in the report under their own N# controllers. Still that odd issue with the last parity device being stored as the USB device. And then none of my disks actually show up. I did think of a different lookup and storage system, by the way - multi-dimensional arrays. Make an array for Controllers. For each controller make a new array named as that controller. For the first element of that array, place your desired product info string(s). Create a new array for disks. Add disks to that array. Place the array of disks as the second element of the controller array. Add that array to the array of Controllers. When going to print the data you'd then: foreach Controller in $Controllers; do printf "$Controller[0];" foreach Disk in $Controller[1]; do printf "$Disk" done done This way it becomes less possible to transpose disks across the array structure. Not sure if this is a viable approach with the formatting you want to do, though.

The drive is part of a btrfs raid 1. The primary disk is mounted and the secondary disk gets identical data written to it in this case. At least that's how I understand it. I see activity on both of them when I write data to the cache volume - so I assume its working as intended, though I haven't bothered to read into it. I'm considering migrating from the Raid1 setup to a Raid0 setup when I get my 10gbe network going. I plan on having 10gbe inside the rack with a 10gbe uplink to the switch, using a dual-10gbe card. Meaning the server could easily see 20gb/s if I really hit it. Especially when migrating data from older server(s) and/or working with disk images while streaming. Oh - and to clarify - df only reports mounted filesystems

Interestingly, running 'grep "rdevStatus" didn't work, but grep -i "rdevstatus" did: root@BlackHole:~# mdcmd status | grep -i "rdevstatus" rdevStatus.0=DISK_OK rdevStatus.1=DISK_OK rdevStatus.2=DISK_OK rdevStatus.3=DISK_OK rdevStatus.4=DISK_OK rdevStatus.5=DISK_OK rdevStatus.6=DISK_OK rdevStatus.7=DISK_OK rdevStatus.8=DISK_OK rdevStatus.9=DISK_OK rdevStatus.10=DISK_OK rdevStatus.11=DISK_OK rdevStatus.12=DISK_OK rdevStatus.13=DISK_OK rdevStatus.14=DISK_OK rdevStatus.15=DISK_OK rdevStatus.16=DISK_OK rdevStatus.17=DISK_OK rdevStatus.18=DISK_OK rdevStatus.19=DISK_OK rdevStatus.20=DISK_OK rdevStatus.21=DISK_OK rdevStatus.22=DISK_OK rdevStatus.23=DISK_NP rdevStatus.24=DISK_NP rdevStatus.25=DISK_NP rdevStatus.26=DISK_NP rdevStatus.27=DISK_NP rdevStatus.28=DISK_NP rdevStatus.29=DISK_OK root@BlackHole:~# mdcmd status | grep "rdevStatus" root@BlackHole:~# Similar thing happened with rdevName - I think it may be a web terminal issue, not sure: root@BlackHole:~# mdcmd status | grep "rdevName" root@BlackHole:~# mdcmd status | grep -i "rdevname" rdevName.0=sdy rdevName.1=sdw rdevName.2=sde rdevName.3=sdf rdevName.4=sdg rdevName.5=sdc rdevName.6=sdt rdevName.7=sdd rdevName.8=sdj rdevName.9=sdu rdevName.10=sdh rdevName.11=sdl rdevName.12=sdk rdevName.13=sdb rdevName.14=sdv rdevName.15=sdm rdevName.16=sdn rdevName.17=sdq rdevName.18=sdr rdevName.19=sdo rdevName.20=sds rdevName.21=sdi rdevName.22=sdp rdevName.23= rdevName.24= rdevName.25= rdevName.26= rdevName.27= rdevName.28= rdevName.29=sdx root@BlackHole:~# And finally df -h: root@BlackHole:~# df -h Filesystem Size Used Avail Use% Mounted on rootfs 24G 1.4G 23G 6% / tmpfs 32M 1.3M 31M 5% /run devtmpfs 24G 0 24G 0% /dev tmpfs 24G 0 24G 0% /dev/shm cgroup_root 8.0M 0 8.0M 0% /sys/fs/cgroup tmpfs 128M 904K 128M 1% /var/log /dev/sda1 59G 4.6G 54G 8% /boot /dev/loop0 20M 20M 0 100% /lib/modules /dev/loop1 5.9M 5.9M 0 100% /lib/firmware /dev/md1 7.3T 3.3T 4.1T 45% /mnt/disk1 /dev/md2 7.3T 2.5T 4.9T 34% /mnt/disk2 /dev/md3 7.3T 728G 6.6T 10% /mnt/disk3 /dev/md4 7.3T 728G 6.6T 10% /mnt/disk4 /dev/md5 7.3T 728G 6.6T 10% /mnt/disk5 /dev/md6 7.3T 728G 6.6T 10% /mnt/disk6 /dev/md7 7.3T 728G 6.6T 10% /mnt/disk7 /dev/md8 7.3T 728G 6.6T 10% /mnt/disk8 /dev/md9 7.3T 844G 6.5T 12% /mnt/disk9 /dev/md10 7.3T 728G 6.6T 10% /mnt/disk10 /dev/md11 7.3T 1.4T 6.0T 19% /mnt/disk11 /dev/md12 7.3T 730G 6.6T 10% /mnt/disk12 /dev/md13 7.3T 728G 6.6T 10% /mnt/disk13 /dev/md14 7.3T 728G 6.6T 10% /mnt/disk14 /dev/md15 7.3T 730G 6.6T 10% /mnt/disk15 /dev/md16 7.3T 728G 6.6T 10% /mnt/disk16 /dev/md17 7.3T 730G 6.6T 10% /mnt/disk17 /dev/md18 7.3T 1.4T 6.0T 18% /mnt/disk18 /dev/md19 7.3T 728G 6.6T 10% /mnt/disk19 /dev/md20 7.3T 728G 6.6T 10% /mnt/disk20 /dev/md21 7.3T 734G 6.6T 10% /mnt/disk21 /dev/md22 7.3T 954G 6.4T 13% /mnt/disk22 /dev/nvme0n1p1 954G 100G 854G 11% /mnt/cache shfs 161T 22T 139T 14% /mnt/user0 shfs 161T 22T 140T 14% /mnt/user /dev/loop2 40G 7.9G 31G 21% /var/lib/docker /dev/loop3 1.0G 17M 905M 2% /etc/libvirt shm 64M 0 64M 0% /var/lib/docker/containers/ad97b37af764aa83b3276d7f03807a5486a8885f56fdb77f557e5b78f820e150/mounts/shm shm 64M 0 64M 0% /var/lib/docker/containers/8d286807ba4757698d04b3160d399be1162d0b33dd8cfc6b86bde162bf95f1be/mounts/shm shm 64M 0 64M 0% /var/lib/docker/containers/1eb3ea0e1e716beee08125eb1f4d65e421bf1182860515e1d0926a6f5f24500d/mounts/shm shm 64M 0 64M 0% /var/lib/docker/containers/b6e07ad9a92216ffc1a5dd6ef6206852a466eb2aa4b9dfd5a38a990cc14f7d95/mounts/shm shm 64M 0 64M 0% /var/lib/docker/containers/7935b46776f36856f516675b79cd89261734cea208e0ee25abe162293bde75a2/mounts/shm shm 64M 0 64M 0% /var/lib/docker/containers/47458aa783d0ec7ca0f5bd3171dac3232d29e7f5bfea8058a8b422633afc486e/mounts/shm shm 64M 368K 64M 1% /var/lib/docker/containers/05c5042e739fd6f3e2ac99a4e2f4193ae1fb8059d305587ceb2efe960f280cd8/mounts/shm shm 64M 8.0K 64M 1% /var/lib/docker/containers/a38258d8e8231f6114f033bf8e5f4f36a99e4e0f6ed17948fec61ac54a7369d1/mounts/shm root@BlackHole:~# If you are wondering if my NVME is part of my array - no it is not. Anyways, back to trying to find all the stuff for my actual computer setup so I can get off this tiny laptop where I might be able to actually look at some code.

Correct - you probably have a NVME SSD reporting as a scsi device in the kernel drivers. I'm not sure if this is a kernel change in the 6.7.x as Pauven (I believe) is running a 6.6.x build. But the change I posted above addresses this specific problem. There's some debugging that needs to be done with the disk reporting. These errors are purely for informational output in the report and should not affect the results of the tester.

So uh, this will be a weekend project. Turns out I have 3 pieces of hardware that completely break that entire section of the script. The first one was an easy fix; the nvme ssds break the array declaration because you can't have a ":" in the name of a variable. I reworked your sed line 132 to: < <( sed -e 's/://g' -e 's/\[/scsi/g' -e 's/]//g' < <( lsscsi -H ) That takes care of that, but I feel I should get a bit more "advanced" with it, since we could strip all invalid characters from that area. From there, it vomits on my megaraid controller at line 215. My resulting output, is kind of comical: SCSI Host Controllers and Connected Drives -------------------------------------------------- [0] scsi0 usbstorage - [N:1:1:1] parity sdy /dev/nvme1n1 WDC WD80EMAZ-00W [1] scsi1 megaraidsas - MegaRAID SAS 2008 [Falcon] disk1 sdw WDC WD80EFAX-68L [N:1:1:1] parity sdy /dev/nvme1n1 WDC WD80EMAZ-00W [N0] scsiN0 devnvme0 - [N1] scsiN1 devnvme1 - I uh. I have 24 online 8tb reds. It seems like the associative arrays are off-by-one, but that doesn't explain the duplicated output on the 0 and then 1. I'll have to poke at it with time to sit down and really sink my teeth into it.

I'll be able to test when I get home, going to change the declaration order to: InitVars Getlshw GetDisks ReportHeader ReportFooter Which *should* give me just the header and footer output so I can tinker with this particular problem. I have a feeling the error is in that general area, just need to pinpoint it. One thought is that it could be assigning it properly, and then overwrite it based on the logic being erroneous, but I can't see any obvious logical errors.

scsistring=`echo $scsistring | tr -d "[]"}` - why is this brace here? line 181. Seems a bit... out of place. Even reading the code that defines the context of that line. Also since you are doing a lot to re-arrange the data into a format you like, I don't think I'll mess with that logic. You've already got associative arrays and such; I think we have a small syntax error or other tiny mistake causing erroneous output. The logic looks "okay"

I'll go ahead and warn that since I don't have a desktop setup at the moment and I'm limited to a 720p screen editing this script is not easy. I see what you've done with the associative array - but I think that some systems may not output everything as you assume. So some of the array variables are null or 0 instead of being defined, which results in other logic failing and causing the erroneous output. I don't know if I can debug this with my limited free time at the moment, so I won't make any promises. root@BlackHole:~# tr -d "]" < <( sed 's/\[/scsi/g' < <( lsscsi -H ) > ) scsi0 usb-storage scsi1 megaraid_sas scsiN:0 /dev/nvme0 INTEL SSDPEKNW010T8 BTNH8435071Z1P0B 002C scsiN:1 /dev/nvme1 INTEL SSDPEKNW010T8 BTNH843506KY1P0B 002C root@BlackHole:~# lshw -quiet -short -c storage | grep storage /0/100/1/0 scsi1 storage MegaRAID SAS 2008 [Falcon] /0/100/2.2/0 storage SSDPEKNW020T8 [660p, 2TB] /0/100/2.3/0 storage SSDPEKNW020T8 [660p, 2TB] /0/a1 scsi0 storage root@BlackHole:~# lsscsi -st [0:0:0:0] disk usb:3-9:1.0 /dev/sda 62.7GB [1:0:10:0] enclosu - - [1:0:11:0] disk /dev/sdb 8.00TB [1:0:12:0] disk /dev/sdc 8.00TB [1:0:13:0] disk /dev/sdd 8.00TB [1:0:14:0] disk /dev/sde 8.00TB [1:0:15:0] disk /dev/sdf 8.00TB [1:0:16:0] disk /dev/sdg 8.00TB [1:0:17:0] disk /dev/sdh 8.00TB [1:0:18:0] disk /dev/sdi 8.00TB [1:0:19:0] disk /dev/sdj 8.00TB [1:0:20:0] disk /dev/sdk 8.00TB [1:0:21:0] disk /dev/sdl 8.00TB [1:0:22:0] disk /dev/sdm 8.00TB [1:0:23:0] disk /dev/sdn 8.00TB [1:0:24:0] disk /dev/sdo 8.00TB [1:0:25:0] disk /dev/sdp 8.00TB [1:0:26:0] disk /dev/sdq 8.00TB [1:0:27:0] disk /dev/sdr 8.00TB [1:0:28:0] disk /dev/sds 8.00TB [1:0:29:0] disk /dev/sdt 8.00TB [1:0:30:0] disk /dev/sdu 8.00TB [1:0:31:0] disk /dev/sdv 8.00TB [1:0:32:0] disk /dev/sdw 8.00TB [1:0:33:0] disk /dev/sdx 8.00TB [1:0:34:0] disk /dev/sdy 8.00TB [N:0:1:1] disk pcie 0x8086:0x390d /dev/nvme0n1 1.02TB [N:1:1:1] disk pcie 0x8086:0x390d /dev/nvme1n1 1.02TB root@BlackHole:~# tr -d "]" < <( sed 's/\[/scsi/g' < <( lsscsi -H ) ) scsi0 usb-storage scsi1 megaraid_sas scsiN:0 /dev/nvme0 INTEL SSDPEKNW010T8 BTNH8435071Z1P0B 002C scsiN:1 /dev/nvme1 INTEL SSDPEKNW010T8 BTNH843506KY1P0B 002C for example I think some of my hardware may break your script - note that my NVME SSD's report an extra column (pcie, then the bus address) compared to regular disks.

To solve this, you could discard "low" values if within a threshold, rather than replacing them?

I'll take a look at the sorting and filtering for those drives at the end tonight when I get off work. I have an idea for a good way to process and organize that, but need to see how the information is pulled and whether or not my idea will work. Would you rather them be ordered by Bus position or devfs node (sdX)? Also line 516 - you have "[TOWER]" hard coded. /etc/hostname has the server's name stored in it. I could nitpick over giant blocks of echos but it really is negligible at the end of the day lol.

you can make your script run inside screen automagically, replace shebang and line 2: #!/bin/sh if [ -z "$STY" ]; then exec screen -dm -S screenName /bin/bash "$0"; fi Tweak screenName as appropriate.

To back this up; I note that the umask is never being set by this docker. I think there was an assumption made that plex doesn't really "make" a lot of files not inherently used by itself. His use case is that the DVR functionality of plex does create files. Standard linux umask is 0022 which would create perms of 0644 on files and 0755 on directories. That allows the owner to read/write but not other users (such as SMB users, or anonymous SMB). The "normal" umask on unraid is 0000 which results in 0666 and 0777 for files and directories, respectively. I provided him a script that adds "umask 0000" after line 3 of the /etc/services.d/plex/run script of this docker. I believe this should be sufficient to resolve.

Correct, the PUID and PGID are the UID and GID of the username and group that file ownership is determined with. You can list all the groups, with their ID's using the groups file and a little bit of awkfu to list only the group names and gids: awk -F: '{ print $1,$3 }' /etc/group You can do the same for users: awk -F: '{printf "%s:%s\n",$1,$3}' /etc/passwd *snip* posted relevant info into your other thread. Please avoid crossposting as now we are splitting information into two places instead of one.