• [6.10.0] VNC no longer connects


    nicknick923
    • Minor

    Hey all, Just upgraded from 6.9.2 to 6.10.0 and my VMs VNC no longer connects.

    As far as I know, I'm using default settings, but both of my VMs VNC worked pre-update, and they both don't work post update. The VMs themselves are working, as I can ssh into them, but the VNC itself just loads a failed to connect (Screenshot & diagnostics attached).

     

    Looks like there might be some related logs in the syslog - which if I'm correlating to the system/urls.txt file correctly, I imagine this is the cause

    syslog.txt:

    May 18 05:59:03 Tower nginx: 2022/05/18 05:59:03 [error] 5398#5398: *1406 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:08 Tower nginx: 2022/05/18 05:59:08 [error] 5398#5398: *1529 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5701/ HTTP/1.1", upstream: "http://127.0.0.1:5701/", host: "hash.unraid.net"
    May 18 05:59:11 Tower nginx: 2022/05/18 05:59:11 [error] 5398#5398: *1560 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5701/ HTTP/1.1", upstream: "http://127.0.0.1:5701/", host: "hash.unraid.net"
    May 18 05:59:11 Tower nginx: 2022/05/18 05:59:11 [error] 5398#5398: *1571 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5701/ HTTP/1.1", upstream: "http://127.0.0.1:5701/", host: "hash.unraid.net"
    May 18 05:59:11 Tower nginx: 2022/05/18 05:59:11 [error] 5398#5398: *1574 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5701/ HTTP/1.1", upstream: "http://127.0.0.1:5701/", host: "hash.unraid.net"
    May 18 05:59:12 Tower nginx: 2022/05/18 05:59:12 [error] 5398#5398: *1583 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5701/ HTTP/1.1", upstream: "http://127.0.0.1:5701/", host: "hash.unraid.net"
    May 18 05:59:12 Tower nginx: 2022/05/18 05:59:12 [error] 5398#5398: *1590 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:13 Tower nginx: 2022/05/18 05:59:13 [error] 5398#5398: *1596 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:13 Tower nginx: 2022/05/18 05:59:13 [error] 5398#5398: *1600 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:13 Tower nginx: 2022/05/18 05:59:13 [error] 5398#5398: *1607 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:13 Tower nginx: 2022/05/18 05:59:13 [error] 5398#5398: *1611 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:13 Tower nginx: 2022/05/18 05:59:13 [error] 5398#5398: *1614 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:14 Tower nginx: 2022/05/18 05:59:14 [error] 5398#5398: *1623 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:14 Tower nginx: 2022/05/18 05:59:14 [error] 5398#5398: *1626 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:14 Tower nginx: 2022/05/18 05:59:14 [error] 5398#5398: *1632 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:14 Tower nginx: 2022/05/18 05:59:14 [error] 5398#5398: *1637 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:14 Tower nginx: 2022/05/18 05:59:14 [error] 5398#5398: *1642 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:14 Tower nginx: 2022/05/18 05:59:14 [error] 5398#5398: *1645 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:15 Tower nginx: 2022/05/18 05:59:15 [error] 5398#5398: *1651 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:15 Tower nginx: 2022/05/18 05:59:15 [error] 5398#5398: *1654 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:16 Tower nginx: 2022/05/18 05:59:16 [error] 5398#5398: *1673 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:16 Tower nginx: 2022/05/18 05:59:16 [error] 5398#5398: *1676 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:16 Tower nginx: 2022/05/18 05:59:16 [error] 5398#5398: *1680 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:17 Tower nginx: 2022/05/18 05:59:17 [error] 5398#5398: *1685 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:17 Tower nginx: 2022/05/18 05:59:17 [error] 5398#5398: *1692 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:18 Tower nginx: 2022/05/18 05:59:18 [error] 5398#5398: *1704 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:18 Tower nginx: 2022/05/18 05:59:18 [error] 5398#5398: *1710 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:19 Tower nginx: 2022/05/18 05:59:19 [error] 5398#5398: *1722 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5701/ HTTP/1.1", upstream: "http://127.0.0.1:5701/", host: "hash.unraid.net"
    May 18 05:59:20 Tower nginx: 2022/05/18 05:59:20 [error] 5398#5398: *1740 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"
    May 18 05:59:54 Tower nginx: 2022/05/18 05:59:54 [error] 5398#5398: *2120 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5701/ HTTP/1.1", upstream: "http://127.0.0.1:5701/", host: "hash.unraid.net"
    May 18 05:59:55 Tower nginx: 2022/05/18 05:59:55 [error] 5398#5398: *2137 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.141, server: hash.unraid.net, request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "hash.unraid.net"

    Urls.txt:

    Available URLs:
      (the URL marked with an asterisk is the primary url for this server)
    HTTP IP url: http://192.168.1.100
      (this will redirect to the primary url)
    HTTP url: http://Tower.nicksosinski.com
      (this will redirect to the primary url)
    HTTPS url 1 (self-signed): https://Tower.nicksosinski.com
      (this will redirect to the primary url)
    *HTTPS url 2 (unraid.net): https://hash.unraid.net

     

    image.png.6c9c0d340536a134d055705afefc8ae4.png

    tower-diagnostics-20220518-0611.zip




    User Feedback

    Recommended Comments

    3 minutes ago, ChatNoir said:

    Did you clear your cache/cookies ?

    I have not, but a quick test with incognito suggests this is the solution - follow up - this fixed it

    Edited by nicknick923
    Adding resolution
    • Like 2
    Link to comment

    I am also having this issue with the recent upgrade.  My VM has started up fine and the servers that are run through it started fine so I know the VM is perfect.  But yes, I get this same error.  It happened immediately after I installed 6.10.  I then saw the 6.10.1 come up as an option and figured that might have addressed it but no luck there either.  Yes, deleting the cache DOES work temporarily but what a pain in the ass to have to do that all the time.  I have resorted to using... Gasp... Microsoft Edge to view the VM since then I don't ahve to worry about clearing the cache of my main browser.

    • Like 1
    Link to comment

    I tried to find out what is stored in the cache that causing this problem, so instead of clearing all application cache I looked at the stored data. It looks like the `rxd-init` and `txd-init` cookies are too long and break something.

     

    I would appreciate if someone confirm my findings (as it takes hours to days for this to happen)  - For chrome users:

    - When the problem is active and NoVNC does not connect

    - From the VNC window with the error message press F12

    - Select Application and cookies on the DevTools window

    - Delete the `rxd-init` cookie

    - Press Connect on the NoVNC window

     

    Link to comment
    9 hours ago, thecode said:

    I tried to find out what is stored in the cache that causing this problem, so instead of clearing all application cache I looked at the stored data. It looks like the `rxd-init` and `txd-init` cookies are too long and break something.

     

    I would appreciate if someone confirm my findings (as it takes hours to days for this to happen)  - For chrome users:

    - When the problem is active and NoVNC does not connect

    - From the VNC window with the error message press F12

    - Select Application and cookies on the DevTools window

    - Delete the `rxd-init` cookie

    - Press Connect on the NoVNC window

     

     

    Can confirm, deleting the  'rxd-init' cookie let me connect again without deleting all cookies.

    • Like 2
    Link to comment

    Hello

    Have the same problem here.

    I solved it by just opening anything related to a vnc in a new window in incognito mode (same thing as with deleting the cookie but faster in my opinion).

    I got the same problem when accessing the JDownloader GUI (hosted in a docker container), solved the same way.

    Thank you all for finding the problem.

    Link to comment

    Ok, so now the other bug report, where the more recent discussion was was closed. And we are back here, a bunch of people have that problem and it is easy to recreate, but we are all still here 2,5 weeks after the latest release deleting cookies or using incognito mode every day..

     

    Anyone got a clue on how to fix this?

    Link to comment
    On 6/6/2022 at 10:22 PM, thecode said:

    I would appreciate if someone confirm my findings

     

    It worked for me, but using Firefox on a Mac! You don't press F12 but Option-Command-I to open the Developer Tools window. From that point select the Storage tab and Cookies and delete the 'rdx-init' cookie.

     

    Edited by John_M
    Added more detail
    Link to comment

    The only problem is that it requires doing it every few days. I have also identified that it is not specifically the `rxd-init` but probably a combination of big cookies.

    I know now how to reproduce it every time without clearing cache, but still not how to solve it.

    For example community apps also adds a big cookie to store it's settings so deleting it (ca_data) also  fix the problem, going to CA settings brings back the cookie which will again break VNC.

    The error even hints that something happens during read:

    recv() failed (104: Connection reset by peer) while reading upstream

    So I guess it would be possible to increase the read buffer somewhere, but this would have to be looked by someone from @limetech

    Link to comment

    I can't see it being CA's cookies which cause this.

     

    image.png

     

    And that biggie from CA should always be <500 bytes

    Link to comment
    56 minutes ago, Squid said:

    I can't see it being CA's cookies which cause this.

     

    image.png

     

    And that biggie from CA should always be <500 bytes

    It is not the cookie itself, there is no problem with the size of it my ca_data cookie is 438 bytes while the rxd-init which I first suggested removing is 541 bytes. The total size of all cookies on my system right now which already breaks VNC is 2816 bytes so surely all of  them does not even reach the limit for a single cookie.

     

    However the combination of the size of the cookies breaks something. I will try to find the limit by editing a cookie and reducing the size until it starts working.

     

    @Squid just to be clear this is not CA related. There are also other big cookies. I showed this as an example since it is easy to delete the CA data and let CA create it again, while for example deleting the rxd-init is not easy to reproduce back the problem since it starts small and get larger with time.

     

    Edited by thecode
    Link to comment

    Either way, if it helps currently testing a fix that removes that cookie when it's no longer needed (and it is actually only needed when installing something)

    Link to comment

    So I added a fake cookie (named it "test"), deleted the ca_data and started increasing its payload until the VNC session no longer connects.

    When total of all cookies is 3159 bytes it still works, increasing the cookie by one byte to 3160 breaks VNC and reducing it again by 1 byte fixes VNC. 

    So the limit at least on my system is 3159, now need to figure out where does this limit comes from

     

    EDIT: also checked without SSL, the limit that still work without SSL is 3522

    Edited by thecode
    Link to comment
    On 6/16/2022 at 9:46 PM, Squid said:

    Either way, if it helps currently testing a fix that removes that cookie when it's no longer needed (and it is actually only needed when installing something)

     

    Any updates on this? It has been a while and I'm still deleting cookies everyday, the latest update also didn't change anything.

    Link to comment
    On 7/14/2022 at 8:52 AM, MightyT said:

     

    Any updates on this? It has been a while and I'm still deleting cookies everyday, the latest update also didn't change anything.

     

    So yesterday I once again cleaned out all the cookies for all unraid domains and also reset the settings in cookie-autodelete (a firefox addon I'm using) and now it seems to be stable, maybe it was just a weird edge case with my config.

    Link to comment

    I don't know who can fix this but I'm also having this issue with a TrueNAS VM (The only one I have at this time). I noticed that when the VM is active in the vm tab under graphics it says "vnc:5900" (when off it says "vnc:auto") and when i click on open remote vnc in the address bar it has a spot that looks like it's trying to connect to 5700. I have no clue if this is the issue or not or how/where to change this.

     

    It's not that I use this too often since TrueNAS has it's own web UI but would be nice to have working in case i have to access it or I try another VM if this isn't an isolated issue.

     

    Edit: Unraid Pro 6.10.3 now on a Supermicro X10DRI-T4+ board in my SC846 Chassis. Previously in a Chenbro NR12000 Chassis with a Tyan board, same issue before and after chassis/system swap.

    Edited by Eugene D
    add system info
    Link to comment
    4 hours ago, Eugene D said:

    I don't know who can fix this but I'm also having this issue with a TrueNAS VM (The only one I have at this time). I noticed that when the VM is active in the vm tab under graphics it says "vnc:5900" (when off it says "vnc:auto") and when i click on open remote vnc in the address bar it has a spot that looks like it's trying to connect to 5700. I have no clue if this is the issue or not or how/where to change this.

     

    It's not that I use this too often since TrueNAS has it's own web UI but would be nice to have working in case i have to access it or I try another VM if this isn't an isolated issue.

     

    Edit: Unraid Pro 6.10.3 now on a Supermicro X10DRI-T4+ board in my SC846 Chassis. Previously in a Chenbro NR12000 Chassis with a Tyan board, same issue before and after chassis/system swap.

    This is not related to the issue here, you will get better support creating a new post

    Link to comment

    I'm having the same issue with a CrashPlan docker that uses a VNC interface.

     

    I've referenced this thread here:

     

    If any of you have specific instances of a particular docker or VM type that gives this sort of connectivity error, OR if you aren't using the webGUI Network graph in dashboard and still get the error I'd be grateful if you could add a comment there, so we can drill down to some sort of resolution.

     

    Cheers :)

    • Like 1
    Link to comment

     

    On 8/5/2022 at 6:00 AM, thecode said:

    This is not related to the issue here, you will get better support creating a new post

     

    Going by Nicks initial post (and skimming through the comments) it looks like this is the same issue I'm experiencing. VNC fails to connect yet the VM (TrueNAS in my case) that was setup while back on 6.9.x works fine, but due to non-working vnc I can not access the working VMs vnc window or create any new VMs (pfsense again in my case). Yes I just submitted my own report on here but wanted to clarify its the same issue as described here.

     

    Edit: VNC works in "Private Mode" (Incognito mode) on Firefox.

    Edited by Eugene D
    Link to comment
    1 minute ago, Paul_Ber said:

    Deleted the cookie but if it comes back that will be a pain.

    Look at my linked thread for the *cause* of the cookie.

    If you don't take care of that then it will inevitably return.

     

    (Assuming it's the same root cause I identified.  Please let us know if it's not the case.)

    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
    Add a comment...

    ×   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.


  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.