DDHH

min/max are set to same value; I attempted 2G and 4G

Hello, I have unraid on a QNAP TS-664 running 7.2.3, just upgraded to 7.2.4 but behavior is same on both versions. I initially could boot up from the installation ISO, after clearing cookies noVNC connected successfully, I get selections and configurations done, then the install proceeded and stalled some time through (the bottom progress bar stalled for a long time). Afterwards I tried repeated deletes and recreates and every single time it stalls after the initial ubuntu screen with circular throbber, leaving a blank screen with no mouse or with the usual "X" mouse. I have tried both "safe graphics" and adding nomodeset manually to the grub settings; no change. I have it configured 4G memory, 2cpus pinned, 64G disk, others are the defaults. Any ideas why a first attempt would work partially and subsequent attempts fail almost immediately? Thank you.

Yes. (I connected it to copy over the config.) I'll try with a different name.

Hello, I plugged in a new thumbdrive I was going to use to replace the original boot flash drive in my unraid system. The GUI immediately went to "stopping array" state, and when it finally finished, the new thumbdrive was shown in the flash slot, with no registration key found of course making the array non-startable, and the original thumbdrive shown as an unassigned device. I had to remove the new thumbdrive and refresh the screen to be able to start the array using the original boot flash. There seems to be no reliable way to plug in a second thumbdrive, if only to copy over your configuration; it needs to be done through an intermediary. Do you see this as a problem? (I would expect the original boot flash to retain its status always, only being replaced on a complete machine restart and boot from that flash.) Thank you.

Hello, I have a new 7.2.2 setup, with two drives currently unassigned. One disk should be idle, but it is always showing a little bit of read activity, and cannot be spun down. I have a recollection that on 6.12.x I could spin down unassigned disks reliably. Anyone have an idea how I can investigate this and get the disk fully idle and spun down? Thank you. disk that should be idle is "Dev 1" (sdb)

It's unfortunate that the unraid usb creator utility made an install that would not work! I ended up using rufus to create a FreeDOS usb, then deleted all files and replaced with unraid .zip contents. This worked.

Hello, I tried creating an unRAID USB using the all-in-one tool from the unRAID website; did the make_bootable.bat procedure as admin. This drive did NOT work (was not seen as a bootable media, UEFI-shell device listing does show it as detected). I made a memtest86 USB using its installer, and this works, so I know the QNAP does support booting from USB. It has an EFI folder so I believe it is using UEFI boot. Any ideas why the unRAID utility fails? I don't know enough about things at this moment to be able to determine what the differences are. I can do some investigating with a bit of guidance. If there is a way to replace the memtest86 install on the working USB drive? (maybe just rename the drive and copy over the unRAID files?) Thank you.

For the previous post I had configured the container to use port 8118 as a test to see if the setting was being used, I don't run privoxy myself and nothing else was using port 8118 at the time. In any case, I restored the setting to port 8112 bridged, and issue still exists. Here's the screenshot:

1. no firewalls 2. no vlans 3,4. different browser, different machines, no change 5. wget calls from webterminal shell or from completely separate machine result in a sequence of: # wget http://192.168.0.185:8118/ --2020-07-14 21:26:32-- http://192.168.0.185:8118/ Connecting to 192.168.0.185:8118... connected. HTTP request sent, awaiting response... No data received. Retrying. --2020-07-14 21:26:33-- (try: 2) http://192.168.0.185:8118/ Connecting to 192.168.0.185:8118... connected. HTTP request sent, awaiting response... No data received. Retrying. ... ... which explains the in-container TIME_WAIT sockets - a connection got through albeit immediately ended 6. bridge or br0 both result in the same -- but I found an interesting behavior, a br0 always results in port 8112 bound (ignores configured port), whereas a bridge config will use the configured port number (as seen in the example above; and I can confirm that nothing is at 8112 as it results in "Connection refused") -- add: a. this behavior exists even after removing the container and /mnt/user/appdata/binhex-deluge and adding it fresh; I'll repeat things were working fine a week ago and I don't believe anything is different now with either my network or unraid setup b. unraid webterminal "iptables -L" output reports a set of "Chain DOCKER" rules when net is bridge, none when br0, consistent with other containers I have running

Doubt there is a conflict - right now, I'm setup on br0 with a separate IP address (and other containers on br0, e.g. pihole, work fine). "netstat -al" in-container shows something listening on port 8112 ("tcp 0 0 0.0.0.0:8112 0.0.0.0:* LISTEN") attempting a webui browser connection results in multiple netstat "tcp 0 0 containerid:8112 mypc:highportnum TIME_WAIT" lines appearing "telnet localhost 8112" in-container gets a connection "telnet containerip 8112" from off-container results in an immediate disconnect and a single netstat TIME_WAIT line in-container (but I can telnet to my pihole br0 ip port 80 just fine...?!?!?!) -- add: last few log lines are: 2020-07-12 00:05:02,619 DEBG 'deluge-script' stdout output: [info] Starting Deluge Web UI... 2020-07-12 00:05:03,620 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 140388658095824 for <Subprocess at 140388658098032 with name deluge-script in state RUNNING> (stdout)> 2020-07-12 00:05:03,624 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 140388658095872 for <Subprocess at 140388658098032 with name deluge-script in state RUNNING> (stderr)> 2020-07-12 00:05:03,624 INFO exited: deluge-script (exit status 0; expected) 2020-07-12 00:05:03,624 DEBG received SIGCHLD indicating a child quit

I'm running binhex-deluge, not binhex-delugevpn

I'm seeing this as well. Was working a few days ago, and now firefox is reporting "The connection to the server was reset while the page was loading." Nothing looks out-of-the-ordinary in /config/deluge.log or /config/deluge-web.log Behavior is the same whether I run the container bridged or br0 with its own ip address. Other containers on br0 or bridged network respond just fine. Ideas?