unRAID OS version 6.5.0 Stable Release Available


Recommended Posts

3 hours ago, daemon9th said:

 

Hi,

 

I had the same issue with an Ubuntu 16.04 VM.

The interface I defined in /etc/network/interface had changed its name. Try "ip link show" command and then check configuration set in /etc/network/interfaces.

 

I just had to modify the name, and reload network service (or reboot).

 

Yep, I had the same problem and this fixed it. Should be "/etc/network/interfaces" not "/etc/network/interface" though.

Link to comment
4 hours ago, daemon9th said:

 

Hi,

 

I had the same issue with an Ubuntu 16.04 VM.

The interface I defined in /etc/network/interface had changed its name. Try "ip link show" command and then check configuration set in /etc/network/interfaces.

 

I just had to modify the name, and reload network service (or reboot).

 

Thanks to @bonienl for having looked into this however the fix that @daemon9th described worked for me. Thanks a lot!!!

Link to comment

Not sure if I should post this here or post as an issue somewhere else? I've found what may be a bug in the display of the docker details. It seems the port mappings are for the most part incorrectly mapped. As in, the ports are actually NOT mapped to the host, but they are showing as mapped. I've tried re-building the container, but it still shows this way. I'm sharing screenshots here to show a list from the port maps screen, a sample from the main docker screen, and a view from the command line using `docker ps -a` to show the actual mapped ports. While it doesn't appear to be doing any real harm that I've found yet ... it is very difficult to understand what I'm viewing and see ports used for different containers. 

 

Docker tab main view:

5aac35014e14d_ScreenShot2018-03-16at5_11_47PM.thumb.png.4098cac5817674eac9489f8041e7c694.png

 

Docker container Edit screen showing mapped host ports:

5aac350246035_ScreenShot2018-03-16at5_12_51PM.png.1586e1740f8f7d8668676677ca576f1e.png

 

Command line view from terminal of docker ps -a output:

5aac350320325_ScreenShot2018-03-16at5_18_13PM.thumb.png.13026251106586cc6f701e24d6beb580.png

Link to comment
4 minutes ago, 1activegeek said:

Not sure if I should post this here or post as an issue somewhere else? I've found what may be a bug in the display of the docker details. It seems the port mappings are for the most part incorrectly mapped. As in, the ports are actually NOT mapped to the host, but they are showing as mapped. I've tried re-building the container, but it still shows this way. I'm sharing screenshots here to show a list from the port maps screen, a sample from the main docker screen, and a view from the command line using `docker ps -a` to show the actual mapped ports. While it doesn't appear to be doing any real harm that I've found yet ... it is very difficult to understand what I'm viewing and see ports used for different containers. 

 

Docker tab main view:

5aac35014e14d_ScreenShot2018-03-16at5_11_47PM.thumb.png.4098cac5817674eac9489f8041e7c694.png

 

Docker container Edit screen showing mapped host ports:

5aac350246035_ScreenShot2018-03-16at5_12_51PM.png.1586e1740f8f7d8668676677ca576f1e.png

 

Command line view from terminal of docker ps -a output:

5aac350320325_ScreenShot2018-03-16at5_18_13PM.thumb.png.13026251106586cc6f701e24d6beb580.png

 

Of course you can map the ports multiple times if you use different IPs for all containers. 

If all containers where using bridged network your statement would be true. But from the little we can see from the pictures you posted it looks like you have specified an IP per container. 

Link to comment

Sorry I did not mention that, but these are all on Bridged network, so yes they are all attempting to run on the host IP. Either way, you can see from the command line, that they are not mapped. The docker service is clearly showing something different than the unRAID interface. I can tell you for a fact that unRAID is the one with incorrect information being shown in the interface. The command line docker service is correct. 

 

Edit: Adding network in view of first screen image for further validation

5aac388dce535_ScreenShot2018-03-16at5_34_57PM.thumb.png.449896fa79207409c3d4ebb05311aa4a.png

Edited by 1activegeek
Link to comment
15 minutes ago, 1activegeek said:

can tell you for a fact that unRAID is the one with incorrect information being shown in the interface.

 

Well the docker command is used to get the port bindings, like this:

docker inspect --format='{{range $p,$c := .HostConfig.PortBindings}}{{$p}}:{{(index $c 0).HostPort}}|{{end}}' <container>

Perhaps something gets confused because of your "bridge2" declaration.

Can you try the above command on one of your 'suspect' containers?

Edited by bonienl
Link to comment
16 minutes ago, 1activegeek said:

Sorry I did not mention that, but these are all on Bridged network, so yes they are all attempting to run on the host IP. Either way, you can see from the command line, that they are not mapped. The docker service is clearly showing something different than the unRAID interface. I can tell you for a fact that unRAID is the one with incorrect information being shown in the interface. The command line docker service is correct. 

 

Edit: Adding network in view of first screen image for further validation

5aac388dce535_ScreenShot2018-03-16at5_34_57PM.thumb.png.449896fa79207409c3d4ebb05311aa4a.png

 

Bridge was not really the correct choice of word from me. 

You have set every container to their own IP. It shows that in your screenshot. Then it's not using the host IP. 

Link to comment
7 minutes ago, bonienl said:

 

Well the docker command is used to get the port bindings, like this:


docker inspect --format='{{range $p,$c := .HostConfig.PortBindings}}{{$p}}:{{(index $c 0).HostPort}}|{{end}}' <container>

Perhaps something gets confused because of your "bridge2" declaration.

Can you try the above command on one of your 'suspect' containers?

 

Running this command shows nothing for containers that are not mapping their ports, as expected. Tried a container that IS mapping ports, and it shows properly.

 

5 minutes ago, saarg said:

 

Bridge was not really the correct choice of word from me. 

You have set every container to their own IP. It shows that in your screenshot. Then it's not using the host IP. 

 

I think we're really digging into semantics that are not of importance. These have their own IP, because they are on the bridge. By default, docker will assign each container it's own IP. That has no bearing on MAPPING of ports. If I'm mapping a port on my host (which is what the mapped host ports sections shows) then I am trying to tie 443 for example on my HOST IP to 443 in my CONTAINER IP. So I don't think talking about the IP of containers is important here as they SHOULD have an IP. What I would expect to see differently with the IP info though, is that I should see something like 172.18.0.12:443 -> 10.0.10.22:443 for a port that is ACTUALLY mapped per the container config to the HOST. But I don't see this either.

 

Some more details of 2 containers in particular one mapped, one not. 

 

Guacamole here IS NOT mapped to the host, is part of the bridge network and SHOULD get a 172.18.x.x IP. You can see the details screen has no Port mapping.

5aac3e39cfb0b_ScreenShot2018-03-16at5_52_45PM.thumb.png.e3f551248d72892f53c0ffe607339ece.png5aac3e3f0c687_ScreenShot2018-03-16at5_53_04PM.thumb.png.094b5b63f1fee59aff39565d3be669fb.png

 

cAdvisor here IS MAPPED to a host port of 8080 as can be seen in the settings/config as well, but it does also still have it's own IP as expected

5aac3e8ac839b_ScreenShot2018-03-16at6_00_05PM.png.768c0497b076c9af997af6bd213e2db6.png5aac3e8fb5532_ScreenShot2018-03-16at6_00_16PM.thumb.png.df8ea92356b69b6274a5c98aab804bf6.png

Link to comment

Ok, I found the reason.

 

The display list uses the outout of the command I have given earlier when the type of network is set to "bridge". For any other type it assumes host or macvlan mode and looks for exposed ports.

 

In your case the other network is "bridge2" which should be treated as "bridge", but it isn't.

 

That happens when "user defined" networks are used (you have bridge2 and localnet and perhaps more?) :/

 

I made a update to address "user defined" networks.

Thanks for reporting.

Edited by bonienl
Link to comment
2 minutes ago, bonienl said:

Ok, I found the reason.

 

The display list uses the outout of the command I have given earlier when the type of network is set to "bridge". For any other type it assumes host or macvlan mode and looks for exposed ports.

 

In your case the other network is "bridge2" which should be treated as "bridge", but it isn't.

 

That happens when "user defined" networks are used (you have bridge2 and localnet and perhaps more?) :/

 

Ok, but the "type" would equal the driver no? 

username@unraid:~$ docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
e862a38c5fe1        bridge              bridge              local
075df9b08ac4        bridge2             bridge              local
0dfca2d1d148        host                host                local
a09a118a7922        localnet            macvlan             local
d5e104f60e1b        none                null                local

So why wouldn't it see bridge2 as a bridge? 

 

And the backstory to explain WHY I'm using this customer bridge - is for DNS name resolution of containers. Using link and other mentions of containers in descriptors is said to be deprecated, so I don't want to use deprecated mechanisms to connect my containers. I run about 30 containers. 24 or so, are run though nginx to expose their services. Using the non-default bridge, has DNS naming of containers enabled. So I can resolve the name of guacamole, cadvisor, etc from the nginx container. Traffic then no longer needs to flow out the docker network then back in through the host networking. It removes extra hops in transmission, removes an issue with macvlan connectivity on the SAME port, and reduces attack footprint on the system. So I'm EXTREMELY hesitant to move back to having to use the default bridge network - unless someone knows a way to enable dns name resolution! (I've not found a way)

  • Upvote 1
Link to comment

Morning all, after installing the 6.5 update yesterday and rebooting i've had a about 3 out of 7 dockers disappear (Sonarr, Radarr, Jackett)

Additionally, I have updates required to be installed for "Fix Common Problems" and "Community Applications", and when attempting to update, I'm getting "plugin not installed".

 

It sounds like something has been remapped, i'm not sure. I haven't attempted to reinstall yet as I'm hoping to retain config and do it the right way (read: the way someone tell me ;) )

Also getting "wrong csrf_token" in the log for "Advanced Buttons" and "Fix Common Problems" plugins.

 

/mnt/cache/appdata still has the missing docker folders too.

 

Any help would be greatly appreciated, cheers

Link to comment
4 minutes ago, bonienl said:

Update will come with the next unRAID release. If all goes according to plan, this will be soon (tm)

 

Ps. Nothing is broken for you, just the display.

Correct, that's what I was trying to illustrate earlier. It's all FUNCTIONING as expected, thankfully ;) - but it's just utterly useless from a WebUI viewpoint. I can no longer tell what's mapped, what isn't type scenario. And it just threw me for a loop seeing ALL that data after I upgraded. Thanks for the help and for the quick update. I'll keep an eye out for the next update for sure. B|

Edited by 1activegeek
Link to comment

Well, that was the first upgrade I've done with UnRAID (6.4.1 to 6.5)......I like easy....and this was easy. Thank you

 

Update: Actually, I have a minor problem. Every time I try to ssh into my server....I just get "permission denied (publickey, keyboard-interactive)"

 

Already tried deleting all the files in my boot/config/ssh folder and rebooting server...still get same problem

Update 2: Uninstalled SSH Plugin, Cleared /boot/config/ssh folder and rebooted again....problem seems fine now. That SSH plugin seemed to be the problem child. Anyway, sorry to bother everyone.

Edited by Stupifier
Link to comment

Only issue I have started getting with this release is with the new VNC.

My OSX VM didn't have issues with mouse use, now it does.

Essentially, the mouse moves in the VNC window, and on windows (background). 

Due to the differences in mouse speed, the windows one always hits the top of the page sooner etc.

Link to comment
Mar 14 22:23:21 Ruby emhttpd: error: get_key_info, 584: Invalid argument (22): get_message: /boot/config/._Pro1.key (-3)
Mar 14 22:23:22 Ruby emhttpd: error: get_key_info, 584: Invalid argument (22): get_message: /boot/config/._Pro1.key (-3)
Mar 14 22:23:23 Ruby emhttpd: error: get_key_info, 584: Invalid argument (22): get_message: /boot/config/._Pro1.key (-3)
Mar 14 22:23:25 Ruby emhttpd: error: get_key_info, 584: Invalid argument (22): get_message: /boot/config/._Pro1.key (-3)
Mar 14 22:23:26 Ruby emhttpd: error: get_key_info, 584: Invalid argument (22): get_message: /boot/config/._Pro1.key (-3)
Mar 14 22:23:27 Ruby emhttpd: error: get_key_info, 584: Invalid argument (22): get_message: /boot/config/._Pro1.key (-3)
Mar 14 22:23:28 Ruby emhttpd: error: get_key_info, 584: Invalid argument (22): get_message: /boot/config/._Pro1.key (-3)
Mar 14 22:23:29 Ruby emhttpd: error: get_key_info, 584: Invalid argument (22): get_message: /boot/config/._Pro1.key (-3)
Mar 14 22:23:30 Ruby emhttpd: error: get_key_info, 584: Invalid argument (22): get_message: /boot/config/._Pro1.key (-3)
Mar 14 22:23:31 Ruby emhttpd: error: get_key_info, 584: Invalid argument (22): get_message: /boot/config/._Pro1.key (-3)
Mar 14 22:23:39 Ruby shfs: error: get_key_info, 584: Invalid argument (22): get_message: /boot/config/._Pro1.key (-3)
Mar 14 22:23:39 Ruby shfs: error: get_key_info, 584: Invalid argument (22): get_message: /boot/config/._Pro1.key (-3)
Mar 15 06:07:49 Ruby root: error: /webGui/include/DeviceList.php: wrong csrf_token
Mar 15 06:07:49 Ruby root: error: /webGui/include/DeviceList.php: wrong csrf_token
Mar 15 06:07:49 Ruby root: error: /webGui/include/DeviceList.php: wrong csrf_token
Mar 15 06:07:49 Ruby root: error: /webGui/include/DeviceList.php: wrong csrf_token

I get these now, since being on 6.4 & 6.5. I haven’t touched my flash drive in years, should I put my pro key somewhere specific? It never stops the license from working however. 

Link to comment
3 minutes ago, Ockingshay said:

I get these now, since being on 6.4 & 6.5. I haven’t touched my flash drive in years, should I put my pro key somewhere specific? It never stops the license from working however. 

 

It's complaining that file "._Pro1.key" is not a valid key file.  It's checking it because it has ".key" extension.  You can delete/rename it.

Link to comment
1 minute ago, Ockingshay said:

...
Mar 14 22:23:39 Ruby shfs: error: get_key_info, 584: Invalid argument (22): get_message: /boot/config/._Pro1.key (-3)
...

I get these now, since being on 6.4 & 6.5. I haven’t touched my flash drive in years, should I put my pro key somewhere specific? It never stops the license from working however. 

 

Do you have a file config/._Pro1.key? It might be hidden if viewed over SSH/console.

 

Your key will be config/Pro1.key

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.