ishcabittle

sorry it took a week to see this, but it was my understanding that the OP was going to change the way that this worked so it wouldn't conflict. My vnc.ini is now using environment variables as well: command=/usr/bin/x11vnc -display %(ENV_DISPLAY)s -frbport %(ENV_PORT_VNC)s -shared -forever I haven't touched this in a while, I set the networking to custom : br0 and have been playing things via a browser. I was going to check back and see if the template surfaced these variables but it doesn't look like that's the case.

Answered my own question: Open the Console of the container Edit: /etc/supervisor.d/vnc.ini Change both of the "5900" to "5909" or similar, your choice, just don't be the same port one of your VMs is running on.

Is there a way to change the port that noVNC is using? If you set the networking to "HOST", noVNC uses 5900 and that is already assigned to one of my VMs. I go to http://<unraidIP>:8083 and it brings up the noVNC connect page, when I click connect with audio enabled it bombs out, and when I click connect without audio I get to my pfSense VM.

Kudos for this, what an excellent surprise to find your container in the apps tab today! I didn't read "Option path to your games. This path will need to also be configured in Steam after the first boot." and installed a game to the /home/default/.steam directory, but that was fixed shortly thereafter. Thank you very much for this excellent container!

Thank you, glennv, that did the trick.

Could you describe this process? I am googling for this procedure and not finding anything significant.

Throwing my hat into the boot loop pile. At first I thought I was not following the directions precisely, but seeing others with the same experience I feel more confident I'm doing things correctly and it is just bugging out.

That was the solution, using the sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID <longPSIDstringhere> /dev/daX command wiped whatever security lock was on the drive and after rebooting from TrueNAS I was able to build my array, all drives adding normally. Thanks again for your assistance, time to populate the array with data!

Inspecting the labels on these drives shows a PSID, which indicates they are SED (self encrypting drives). According to this article: https://www.truenas.com/docs/core/storage/sed/ you can unlock the drives with the PSID on the label using the sedutils-cli command in TrueNAS. I'm going to install TrueNAS on a flash drive and see if I can unlock them with those very long PSIDs. If that doesn't work, I may have to reflash my h710p back to stock and have it remove the locks. Oof, what a pain. Thanks for all the help, keep your fingers crossed for me.

Preclear can't verify the Unraid MBR signature either: ############################################################################################################################ # # # unRAID Server: verifying Preclear State of disk 5000c50057ee296b. # # Verifying disk '5000c50057ee296b' for unRAID's Preclear State. # # # # # # Step 1 of 1 - Verifying unRAID's signature: FAIL # # # # # # # # # # # # # # # # # # # # # # # ############################################################################################################################ # Cycle elapsed time: 0:00:00 | Total elapsed time: 0:00:00 # ############################################################################################################################ --> RESULT: FAIL! /dev/sdb DOESN'T have a valid unRAID MBR signature!!!

It is odd... this array was working well in Windows on the pre-flashed Perc h710p, I'm not saying you're wrong but it would be very coincidental for the cables to go between switching OSs. Plus the Preclean scripts had no issues erasing the disks nor writing zeros across all sectors. When I tail the /var/log/syslog and attempt to add a disk to the array, there is some output with this block seeming to be the most relevant: Apr 19 15:24:11 Tower kernel: sd 1:0:6:0: [sdh] tag#3435 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s Apr 19 15:24:11 Tower kernel: sd 1:0:6:0: [sdh] tag#3435 Sense Key : 0x7 [current] Apr 19 15:24:11 Tower kernel: sd 1:0:6:0: [sdh] tag#3435 ASC=0x20 ASCQ=0x2 Apr 19 15:24:11 Tower kernel: sd 1:0:6:0: [sdh] tag#3435 CDB: opcode=0x28 28 00 00 00 00 00 00 00 20 00 Apr 19 15:24:11 Tower kernel: blk_update_request: critical target error, dev sdh, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0 Apr 19 15:24:11 Tower kernel: sd 1:0:6:0: [sdh] tag#5249 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s Apr 19 15:24:11 Tower kernel: sd 1:0:6:0: [sdh] tag#5249 Sense Key : 0x7 [current] Apr 19 15:24:11 Tower kernel: sd 1:0:6:0: [sdh] tag#5249 ASC=0x20 ASCQ=0x2 Apr 19 15:24:11 Tower kernel: sd 1:0:6:0: [sdh] tag#5249 CDB: opcode=0x28 28 00 00 00 00 00 00 00 08 00 Apr 19 15:24:11 Tower kernel: blk_update_request: critical target error, dev sdh, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Apr 19 15:24:11 Tower kernel: Buffer I/O error on dev sdh, logical block 0, async page read Apr 19 15:24:11 Tower emhttpd: error: ckmbr, 2197: Input/output error (5): read: /dev/sdh Apr 19 15:24:11 Tower emhttpd: ckmbr error: -1 The iDRAC on this box (pre flash) used to show seven out of the eight disks as "secured", I wonder if there isn't some lockdown that Dell has in place that ensures genuine disks or something similar.

See attached diags - this was taken shortly after attempting to add disks, a few minutes after a reboot. tower-diagnostics-20210419-1433.zip

I have booted Unraid on my r720xd with a newly flashed IT mode h710p mini d1 SAS card. Devices are seen normally, all smart status are green, and I am attempting to add disks to the array. I have successfully added one out of 8, the remaining seven are listed in unassigned devices, and when I attempt to add a disk, it looks like it adds for a split second then returns to "unassigned". I installed the Preclear plugin and erased each disk and its MBR, I've rebooted after resetting the config, I'm not precisely sure what to do from here. Diags to come after post approval.