phil1c

Easy enough. Thanks for confirming.

@scolcipitato Could you point me in the right direction for my question here?

I'm transitioning certain containers to compose stacks. I use folders to sort by the primary function of groups of containers (ie: media related, system utilities, network utilities, documentation, etc). When using labels in my compose files, I assign all if the containers of a stack to the folder corresponding with the overall function (ex: my nextcloud stack has a mariadb container, a redis container, a container for Collabora, and the nextcloud container; these all get assigned to my "file management" folder). I'd like to be able to keep those containers sorted next to each other within the folder. However, I can't rearrange any of the containers in a compose stack when they're added via labels. Is there some other way besides the normal drag-n-drop to rearrange these containers in each folder? Containers from compose stacks in a folder: Edit Folder page. Note the grayed-out "Included" toggle for compose containers. They cannot be dragged to move.

Thanks for taking a stab at it! I made the changes and encountered some additional issues and had a couple suggestions so I made a comment on that PR. We can discuss further over there to avoid cluttering up this forum.

Sorry, I was being very specific: bond0.43 uses macvlan drivers. docker network inspect bond0.43 [ { "Name": "bond0.43", "Id": "48d92dd914b3319138296b5016da749e795767b808632b2a87c37eb851444d9c", "Created": "2024-07-17T08:00:11.865073653-04:00", "Scope": "local", "Driver": "macvlan", ....

Bond0 is a bonded group of 2x 1gbe network connections using 802.3ad mode. Bond0.43 is a subinterface for accessing VLAN43 where I segment all dockers and VMs on this machine. Docker uses macvlan for custom network types. If there is something else you want to know about my network, let me know. I understand that this may be a bug with Dockerman, but still happy to help satisfy curiosities to determine a root cause.

Ok. I commented out all references to the external bond043 network. I wiped the docker.json and brought the stack up and it worked! I now have proper WebUI links. Of course, I'd like to keep my dockers on that separate external network. How else do you need me to troubleshoot to help determine the root cause? For reference, my compose file and override file (which do generate the correct webui URL) look like this now: docker-compose.yml services: makemkv: container_name: pluginMakemkvTest # networks: # - bond043 ports: - 5910:5900 - 6090:6080 privileged: true environment: - TZ=America/New_York - WEBPAGE_TITLE=MakeMKVplugin - VNC_PASSWORD= - ENABLE_STARTUP_SCRIPTS=yes - UMASK=000 - PUID=99 - PGID=100 volumes: - /mnt/user:/media:rw - /mnt/cache-unprotected/Downloads/:/downloads:rw - /mnt/cache-protected-refresh/appdata/dockgeMakemkvTest:/config:rw image: binhex/arch-makemkv #networks: # bond043: # name: bond0.43 # external: true docker-compose.override.yml services: makemkv: labels: net.unraid.docker.managed: 'composeman' net.unraid.docker.icon: '${ICON_URL}' net.unraid.docker.webui: 'http://[IP]:[PORT:6080]/vnc.html?resize=remote&host=[IP]&port=[PORT:6080]&autoconnect=1' net.unraid.docker.shell: 'bash'

Do you have a moment to look at my update posts detailing my further investigation into the issue I'm facing?

I found this post and followed the instructions to force the recreation of the docker.json file to manually fix this. You can take a look at my previous post to see the steps I tried already.

Ok, I found the matching override files as you described above and made the relevant changes, as below: services: makemkv: labels: net.unraid.docker.managed: 'composeman' net.unraid.docker.icon: '${ICON_URL}' net.unraid.docker.webui: 'http://[IP]:[PORT:6080]/vnc.html?resize=remote&host=[IP]&port=[PORT:6080]&autoconnect=1' net.unraid.docker.shell: 'bash' After making the changes, I followed the instructions here to force the update of the plugins docker.json file to grab the new webui URL. This worked as I temporarily set the url to google just to make sure the change was occurring and that it was a link (successful: webui link opened a tab to google . com), after which I returned it to the value above. However, still the url was not "rendered" into an actual link. The override file is as described above and the docker.json shows the following: "pluginMakemkvTest": { "running": true, ... "url": "http://[IP]:[PORT:6080]/vnc.html?resize=remote&host=[IP]&port=[PORT:6080]&autoconnect=1", "icon": "/state/plugins/dynamix.docker.manager/images/pluginMakemkvTest-icon.png", ... }, and 'docker inspect pluginMakemkvTest' shows the following: "net.unraid.docker.managed": "composeman", "net.unraid.docker.shell": "bash", "net.unraid.docker.webui": "http://[IP]:[PORT:6080]/vnc.html?resize=remote&host=[IP]&port=[PORT:6080]&autoconnect=1", So the value from the override is being correctly passed to the docker manager, it's just not being parsed into a url, it's being taken wholesale as a text string. Out of curiosity, I changed the webui url again (in the override file) to the exact same "webui URL" of a totally unrelated but running container, forced the recreation of the docker.json file, and spun up the compose stack. Still, the webui URL does not parse: docker.json "pluginMakemkvTest": { "running": true, ... "url": "http://[IP]:[PORT:8989]", "icon": "/state/plugins/dynamix.docker.manager/images/pluginMakemkvTest-icon.png", docker inspect "net.unraid.docker.managed": "composeman", "net.unraid.docker.shell": "bash", "net.unraid.docker.webui": "http://[IP]:[PORT:8989]", I'm not sure what's relevant here, so I'll add: Looking at the docker.json file, all of my running containers with webui URLs have a properly parsed url. All of the non-running containers show the raw text used to create the URL. Running container from docker.json "librespeed": { "running": true, ... "url": "http://actual.IPv4.address:80", Non-running container from docker.json "DiskSpeed": { "running": false, ... "url": "http://[IP]:[PORT:8888]/", The icon URL correctly pulls the url from the .env variables EDIT: Adding here: when i inspect the rendered HTML of the Docker tab page, I do see the updated URL ("http://[IP]:[PORT:8989]") as the url for the webui link, so the url string is going from override file > docker manager > compose plugin docker.json AND rendered Docker tab webpage. Is there something that is supposed to trigger docker manager to parse the webui URL into an actual link upon starting a container that isn't occurring when using the compose plugin? Happy to do more digging/troubleshooting to help sort this out.

Ok, so for now I can either manually incorporate the changes made there or wait for Unraid to merge the changes, correct? Have you used these changes? I see a comment that it breaks editing existing containers (here) : is this true? Thanks for the suggestion. I added quotes and yet still nothing. I inspected the rendered HTML of the page to see what link was created and I have the following: When I check on a similar container created using the unraid UI, I see the following: function onclick(event) { addDockerContainerContext('binhex-makemkv', '096fa2b590ee', '/boot/config/plugins/dockerMan/templates-user/my-binhex-makemkv.xml', 1, 0, 0, false, 'http://10.43.64.31:6080/vnc.html?resize=remote&host=10.43.64.31&port=6080&autoconnect=1', .... You can see the link was "rendered" (for lack of a better term) from the webUI URL entered in the container template, same as above. When I check on the compose-stack-created single container, i see the following: unction onclick(event) { addDockerContainerContext('pluginMakemkvTest', '096fa2b590ee', '', 1, 0, 3, false, 'http://[IP]:[PORT:6080]/vnc.html?resize=remote&host=[IP]&port=[PORT:6080]&autoconnect=1', As you can see, in the case of the compose stack container, the "webUI URL" is entered directly as typed into the "UI Labels" field. This does not change if I add quotes, remove them, enter the webUI URL into the UI Labels field, nor if I leave the UI Labels field blank and only leave the For some reason, the compose created container isn't actually "generating" the webUI from the given template. I'm on 6.12.10 if that makes a difference.

I'm testing switching to compose and I have a couple questions that I haven't been able to address from previous posts: I understand that the way network names are displayed (ie: some very long string of characters) is due to dockerman. Is there anything in the works to address this other than overriding "network_mode" in the compose.yml? The test container (single container stack) that I've spun up doesn't show port mappings in the Unraid UI either. Is there a way for me to address this? I have the following webui label added to the compose.yml: net.unraid.docker.webui=http://[IP]:[PORT:6080]/vnc.html?resize=remote&host=[IP]&port=[PORT:6080]&autoconnect=1 However, when I select the container icon and click "WebUI" no new page/tab attempts to open. Is there something else I must do to make container webui links work? I have already attempted to restart the entire server hoping it was an issue with webUI URLs "sticking" as I'd seen mentioned in other posts but. Additionally, if I create a matching container from the Unraid GUI with the same webui url it works without issue. Any help would be appreciated. My stack is as follows services: makemkv: container_name: pluginMakemkvTest networks: - bond043 ports: - 5900:5900 - 6080:6080 privileged: true environment: - TZ=America/New_York - WEBPAGE_TITLE=MakeMKVplugin - VNC_PASSWORD= - ENABLE_STARTUP_SCRIPTS=yes - UMASK=000 - PUID=99 - PGID=100 volumes: - /mnt/user:/media:rw - /mnt/cache-unprotected/Downloads/:/downloads:rw - /mnt/cache-protected-refresh/appdata/dockgeMakemkvTest:/config:rw labels: - net.unraid.docker.icon=https://raw.githubusercontent.com/binhex/docker-templates/master/binhex/images/makemkv-icon.png - net.unraid.docker.webui=http://[IP]:[PORT:6080]/vnc.html?resize=remote&host=[IP]&port=[PORT:6080]&autoconnect=1 image: binhex/arch-makemkv networks: bond043: name: bond0.43 external: true

Bump. Any way to do what I'm asking?

I would like to use the name of the docker container in the "WebUI" field instead of [IP] or [PORT:xxx] so that I could write a webui value of "https://[NAME].local". I have tried [name], [NAME], and [Name] and none have worked. Is something similar to container name an available option for variables in the WebUI field? And are their other variables available?

Just installed Unmanic for the first time just now and I'm trying to get everything setup. For reasons I don't know there are no plugins available and "Refresh Repositories" displays a message that it completed the refresh but still nothing. I've tried wiping appdata and deleting and reinstalling the docker container but no change. Any advice on how to get the plugins to show up?

Ok. I didn't change anything else except I updated from PuTTY 0.73 to 0.74 and now it works no issue from my Win10 machine. I'm on Unraid 6.9.0 beta35.

Yeah, this is where I was/am at. Works no issue from my Macbook but Putty on my Win10 desktop refuses to work.

Thanks, but I already tried that. No help.

I'm having that exact issue all of a sudden (the one described by grantbey above) and already tried: cd / chown root:root . and chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys and I've verified that my public key (that I've used for over a year) is in the authorized_keys file. When the key log in fails, I can log in with password. I'm also using the "built-in" functionality of unRAID (I forget what version it was introduced) where, placing a folder in /boot/config/ssh/ titled "root" automatically get's symlinked from ~/.ssh/ so I don't use a script to copy an updated sshd_config. I'm on the nvidia-plugin version of 6.9.0beta30. Any other ideas what I could try?

So, another person to throw their hat into this ring, as I am having the same issue, but I happened to see something possibly interesting (or maybe entirely irrelevant) before the issue started. Unraid Version 6.8.3 (NVIDIA build) Drive: LG WH16NS60, mounted internally via SATA. came with firmware 1.02 BEFORE PATCHING: Upon first installation of the drive into my Unraid machine, I installed and fired up the binhex-makemkv docker, and the drive was, with no changes to the template or extra parameters (privileged mode), visible in MakeMKV. Great! Time to flash a new firmware. I fired up a Win10 VM, passed the drive through, and flashed with a patched version of the 1.02 firmware (1.02-MK) so I can backup blu-rays. I tested it in the VM, ripped a basic Blu-Ray, no issues. AFTER PATCHING: Ok, turn off the VM. Reboot the server, just cause. Fire up the MakeMKV docker (privileged mode), and poof, no drive. I edited the docker to set PUID and PGID to 0 each, restarted the docker, and bam the drive is visible. One more strange note: In the Win10 VM, under LibreDrive Information, all of the statuses below "firmware version" show "Yes", but in the MakeMKV docker, "Unrestricted read speed" shows "possible, not yet enabled". There at least seems to be a difference in performance as the read speed seems to be limited at a steady 15MB/s read from the docker, but manages almost 30MB/s from Win10. Already have a correction: I re-ran the test in the WIn10 VM to make sure I was ripping the same exact stream from the disk and the speeds are nearly identical (16MB/s) to what the docker was able to read (15.4MB/s), so I guess I originally ripped a different stream further to the edge of the disc. Maybe there is something strange with the firmware causing the drive not to be recognized by the docker with the default 99/100 PUID/PGID? I have no idea how that would be, but that's the only thing that changed between the first boot-up and then using the patched version.

Hey! I was having the same problem and eventually gave up. If you get this sorted, let me know. I will gladly try and help track this down again because it drives me nuts. For reference below are a few links to my own troubleshooting that I tried months ago, both from this post and from UBNT forums. Do note that my set up has changed since some of those posts in that I now have an EdgeSwitch8 instead of an Asus router in AP mode referenced in some of the posts. That change had no effect. If it lends itself to some other connection, I also cannot browse to my domain website (Ombi) from within my network. The UBNT rep suggested a static host map, but that brings me to an "ERR_CONNECTION_REFUSED" page when attempting to go through my domain. Initial Post: Follow-up: UBNT and exchange with UBNT support https://community.ui.com/questions/UNMS-WSS-key-using-WAN-IP-device-connection-times-out/7ea01845-1b3d-41a9-9555-172e8ecbd4b0

I, too, am having issues getting the UNMS docker to work, though mine are when I try and use an external domain and reverse proxy to reach UNMS: First, you can find some more information on my issue here (trying to crosspost as I'm not strictly sure of where the issue is arising from): link Short version is: I have the LSIO Let's Encrypt docker (tried it with the NGINX Proxy Manager one as well) running and working (serving other dockers externally). I also have the oznu/unms docker installed and running. I can add my ER4 to UNMS if I use tower.local:6443 (internal) as the UNMS server name in the host key but when I try to use unms.my.domain (external), UNMS connects and passes credentials to the ER4 but the ER4 never connects. Setup Note I have set the UNMS docker set up with PUBLIC_HTTPS_PORT and PUBLIC_WS_PORT set up to 6443 as that is the port assigned for SSL to the docker container. So, internally, I use tower.local:6443, and this is what NGINX routes to for unms.my.domain. However, if I remove the two PUBLIC assignments, none of the below troubleshooting results change. Also, unms.my.domain and unms.my.domain:443 both work to access the UNMS webUI externally but unms.my.domain:6443 fails to connect nor is it reachable by ping. New Troubleshooting: 1. In the unms.log on my er4, this is repeated over and over: 2019-03-29 21:23:00 ERROR connection error (unms.my.domain:443): HS: ws upgrade response not 101 - This is returned whether I use NGINX Proxy Manager with "Websockets Support" enabled or if done through LE. - When using tower.local, I receive the following and the er4 connects to UNMS fine: 2019-03-30 17:08:23 INFO unms: connecting to tower.local:6443 2019-03-30 17:08:23 INFO connection established 2019-03-30 17:08:25 INFO got unmsSetup 2. I found this page on support for the official UBNT UNMS docker and tried out the tests within the "Is it possible to ping UNMS from the device?" and "Does the connection upgrade to WebSocket?" sections. Results, from my er4, internal and external are as follows: Is it possible to ping UNMS from the device? Internal: "ping tower.local": completes, no error "traceroute tower.local" and "traceroute 192.168.1.30": completes, one hop "curl --insecure https://192.168.1.30:6443/v2.1/nms/version": version 0.13.3 is returned, which is accurate External "ping unms.my.domain": completes, no error "traceroute unms.my.domain": completes, one hop "curl --insecure https://unms.my.domain:443/v2.1/nms/version": I receive the html for a 404 error page. BUT, if I go to that URL in my browser, I receive a page that only contains '{"version":"0.13.3"}', same as when i run the command command on the local address. I have no idea why this is. Does the connection upgrade to WebSocket? Internal "curl --insecure --include --no-buffer --header "Connection: Upgrade" --header "Upgrade: websocket" --header "Host: example.com:80" --header "Origin: http://example.com:80" --header "Sec-WebSocket-Key: SGVsbG8sIHdvcmxkIQ==" --header "Sec-WebSocket-Version: 13" https://tower.local:6443/" Instead of the header that is supposed to happen as per the help page, I get the following 502 Bad Gateway header followed by the HTML of the "UNMS is starting" landing page: HTTP/1.1 502 Bad Gateway Server: nginx Date: Sat, 30 Mar 2019 17:37:03 GMT Content-Type: text/html Content-Length: 2325 ... Keep in mind, connecting locally WORKS with no issue. External "curl .... https://unms.my.domain:443" Now, I receive the following header, followed by the HTML of the UNMS login page. HTTP/1.1 200 OK X-Frame-Options: SAMEORIGIN X-Xss-Protection: 1; mode=block Content-Length: 8473 ... So, internal access gives me a bad gateway error when using the above curl command but the ER4 can connect, and external access at least passes me the login page with no error but does not perform the websocket upgrade and the er4 fails to connect (which at least explains the "ws upgrade response not 101" error from #1). Sadly, no additional help is provided on what to do next on the referenced UBNT support page. The Cry for Help Is there something that I am missing? Is there something additional that I need to set up in the UNMS docker? I'm continuing to search and learn but I have been smashing against this wall for a couple days now.

So, I'm beating my head against my keyboard trying to get UNMS to work with the letsEncrypt docker and I can't seem to figure it out. I am posting here and a few other places as I'm not sure if this is a failure of the setup of LE or if it's my UNMS docker or something else so sorry if this doesn't fully belong. For the record: I think I'm only just moving out of noob territory when it comes to unRaid/Linux usage so apologies if I fail to include something or miss something obvious. Issue: I cannot get my ER4 to connect to UNMS, even though if i go through the Discovery manager, the UNMS key *will* be automatically populated into my ER4 system settings. Setup (hopefully in a concise order): FQDN for unms access = unms.my.domain (UMD) LetsEncrypt Docker (LED) setup = - port forward on router = WAN:443 --> tower:643 / WAN:80 --> tower:280 - LetsEncrypt ports = tower:643 --> LED:443 / tower:280 --> LED:80 - LED is on a custom Docker network "proxynet", along with Ombi and UNMS docker - config for UMD = # make sure that your dns has a cname set for unifi and that your unifi-controller container is not using a base url server { listen 443 ssl; listen [::]:443 ssl; server_name unms.my.domain include /config/nginx/ssl.conf; client_max_body_size 0; # enable for ldap auth, fill in ldap details in ldap.conf #include /config/nginx/ldap.conf; location / { # enable the next two lines for http auth #auth_basic "Restricted"; #auth_basic_user_file /config/nginx/.htpasswd; # enable the next two lines for ldap auth #auth_request /auth; #error_page 401 =200 /login; include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_unifi unms; proxy_pass https://$upstream_unifi:8443; } location /wss { # enable the next two lines for http auth #auth_basic "Restricted"; #auth_basic_user_file /config/nginx/.htpasswd; # enable the next two lines for ldap auth #auth_request /auth; #error_page 401 =200 /login; include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_unifi unms; proxy_pass https://$upstream_unifi:8443; proxy_buffering off; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; proxy_ssl_verify off; } } UNMS docker (UD) setup (oznu/unms docker template added through Community Apps): - UD port mapping: tower:643 --> UD:443 / tower:6080 --> UD:80 - LetsEncrypt within UD is currently disabled Currently Working: 1) Lets Encrypt docker is currently working: - I can access ombi from outside the network, as can my Plex users. 2) UNMS docker is working from within the local network: - I can access the WebUI, I have set up UNMS. 3) LED --> UD: - If i change port in unms.subdomain.conf from :8443 to :443 (EDIT: wrong port #), I can access the WebUI from the internet at unms.my.domain with no problem. The Failure: When I go into UD and use the Discovery Manager to add my er4, the er4 never completes the connection to UNMS (connection times out). What is confusing to me is that, when I initiate the connection from the Discovery Manager, the credentials are clearly correct along with some portions of forwarding/connects/etc because the UNMS key is then populated in my ER4. However, it always hangs on "device connecting". (EDIT: added this line from more testing) Additionally, if I manually change the fqdn in the UNMS key to tower.lan:6443, the er4 connects to UNMS fine. Is there anything glaring in my configuration that anyone can see as to why connecting to the er4 isn't working? Is there something about port forwarding 443 to LED that's messing with the UNMS connection? I'm just not versed enough in how the actual UNMS --> device connection occurs to better troubleshoot it.

Ok, I got it. I changed the preg_match pattern to "/Temperature.+\-\s+(\d\d).?/im" which just looks for the first pair of digits after a dash and some whitespace and leaves the option for additonal characters after; that relies entirely on "WHEN_FAILED" always being a dash so perhaps it's not the most robust method. To test, I ran it against the similar bottom outputs to what you have, and received the correct temperatures. Now I have it running in the hddtemp script and all of my drives are present and reporting. Let me know if that change works for you as well.

Alright, I have the hddtemp script MOSTLY working (thanks for showing me those), which is why I'm back. The hdtemp script is not returning SOME of my hdd temps; I updated the script to $tagsarray to include all 7 drives but 3 are not returning values. Then I ran smartctl on the and all of my drives, including the ones that are missing, and they show 194 Temperature_Celsius and some show 190 Airflow_Temperature_Cel. Do all of your drives show up appropriately? Did you make any other edits to your script besides what you posted on the thread you listed? My hddtemp.sh script is as follows: #!/usr/bin/php <?php $tagsArray = array( "/dev/sdb", "/dev/sdc", "/dev/sdd", "/dev/sde", "/dev/sdf", "/dev/sdg", "/dev/sdh", "/dev/sdi", ); //do system call and parse output for tag and value foreach ($tagsArray as $tag) { $call = "smartctl -A ".$tag; $output = shell_exec($call); preg_match("/Temperature.+(\d\d)$/im", $output, $match); //send measurement, tag and value to influx sendDB($match[1], $tag); } //end system call //send to influxdb - you will need to change the parameters (influxserverIP, Tower, us-west) in the $curl to your setup, optionally change the telegraf to another database, but you must create the database in influxdb first. telegraf will already exist if you have set up the telegraf agent docker. function sendDB($val, $tagname) { $curl = "curl -i -XPOST 'http://192.168.1.253:8086/write?db=telegraf2' --data-binary 'HDTemp,host=Tower,region=us-east " .$tagname."=".$val."'"; $execsr = exec($curl); } ?>