Rustdesk AIO

Hi! I'm quite new and just trying to figure out how to setup rustdesk, currently it's showing this error

Failed to connect to myip:21116: Please try later

After installing the app I just leave the settings be as default, on rustdesk i put the same address on ID, relay, and API (add http) and the key I already have

Can you please help?

6 hours ago, Kevotsai said:

Failed to connect to myip:21116: Please try later

You just have to put in your ID-Server address (not IP and without the port) and the Public Key that you get in the log.

Then make sure to forward all the ports from the template with the appropriate protocol, that should be it.

This should be safe since this is not a Web application, RustDesk does not run as root inside the container and you have the other benefit of just using your domain name, like: example.net

After update to 7.2.5, the sabnzbd docker isn't serving a webpage or communicating with other dockers. It is starting, but no use. Any ideas why?

unraidpvr-diagnostics-20260501-1701.zip

53 minutes ago, Rick Gillyon said:

After update to 7.2.5, the sabnzbd docker isn't serving a webpage or communicating with other dockers. It is starting, but no use. Any ideas why?

unraidpvr-diagnostics-20260501-1701.zip

Do you route it through another container?

If yes could it be that the VPN container isn't working?

No, it's not routed, it's standard bridge.

Looks like it's crapping out, I had restart-unless-stopped on so it looked like it was running:

  File "/sabnzbd/SABnzbd/sabnzbd/newswrapper.py", line 209, in NewsWrapper
    def on_response(self, response: sabctools.NNTPResponse, article: Optional["sabnzbd.nzb.Article"]) -> None:
                                    ^^^^^^^^^^^^^^^^^^^^^^
AttributeError: module 'sabctools' has no attribute 'NNTPResponse'

Edited May 1May 1 by Rick Gillyon

33 minutes ago, Rick Gillyon said:

Looks like it's crapping out, I had restart-unless-stopped on so it looked like it was running:

From where is that, the container log or the WebUI?

Container log, just clicking on it and hitting Logs.

@Rick Gillyon please update the container, should be fixed.

Thanks, it's running now, but throwing errors in the UI:

I maybe broke something trying to fix it...

These haven't changed:

A little more error under the previous:

Traceback (most recent call last):
  File "/sabnzbd/SABnzbd/sabnzbd/filesystem.py", line 752, in create_all_dirs
    os.mkdir(path_part_combined)
    ~~~~~~~~^^^^^^^^^^^^^^^^^^^^
PermissionError: [Errno 13] Permission denied: '/data'

Edited May 1May 1 by Rick Gillyon

10 minutes ago, Rick Gillyon said:

I maybe broke something trying to fix it...

Looks like you destroyed the permissions, give me a bit, I try that over her, give me a bit.

I can't tell what's wrong now but it seems everything is working over here:

Did you maybe change the permissions or fix the permissions somewhere in Unraid itself?

No, I never changed permissions and those seem to be writable.

Do you think the Fix Permissions utility will help?

What do you have for these:

2 minutes ago, Rick Gillyon said:

Do you think the Fix Permissions utility will help?

No, please don't do that, this will probably mess up the permissions completely.

However, is your config file maybe broken, as you can see from your screenshots above, you now have the directory /data in the container specified however I don't use that in my containers and you even don't use them in the container.

The directories are /mnt/downloads and /mnt/incomplete

Thanks. I had replaced config folder with a backup from last week, I guess it didn't take. So I removed the lot and started again, working now.

As ever, thanks for all the help.

I am having an issue for the last few days with TheLounge docker. Its run perfectly for months but recently its not starting up correctly and the log is throwing an error

---Something went wrong, can't get latest version of TheLounge, putting container into sleep mode---

54 minutes ago, MulletBoy said:

I am having an issue for the last few days with TheLounge docker. Its run perfectly for months but recently its not starting up correctly and the log is throwing an error

This is really strange, however please do note that I deprecated TheLounge over a year ago, if possible, please switch over to the container from Linuxserver.io if possible.

However if the container was running up until now I assume that something in appdata got corrupted or isn't there where it should be. Maybe look if everything is okay with your appdata directory since the deprecation won't affect the function from the container.

On 6/11/2026 at 3:06 AM, MulletBoy said:

I am having an issue for the last few days with TheLounge docker. Its run perfectly for months but recently its not starting up correctly and the log is throwing an error

---Something went wrong, can't get latest version of TheLounge, putting container into sleep mode---

Same

On 6/21/2026 at 10:54 AM, Seraphys said:

Same

I fixed my issue, in appdata/thelounge there was a 0 byte file that appeared to be the (attempted) download of the latest version of TheLounge. I deleted that and restarted the container, fixed my issue.

Hello,

About the Jdownloader docker, I need expose the port 9666 from the jdownloader.
I added port in the docker configuration but that seems dont work.

I think its because novnc

Any idea?

Thx so much.

I'm using Rustdesk-AiO with Unraid Docker.

I'm now getting could not verify end to end encryption since the client update a couple of months ago...

will you be updating the server version to be compatable with new client versions?

On 9/13/2026 at 10:59 PM, tcshavasu said:

will you be updating the server version to be compatable with new client versions?

No issue over here with the latest client version and the newest container version.

The server is on the latest version 1.1.6, please see here and here.

On 9/13/2026 at 10:59 PM, tcshavasu said:

I'm now getting could not verify end to end encryption since the client update a couple of months ago...

Please check your certs for your domain if they are still valid and the keys are correct.

@ich777 Forgive my AI generated report here, but I spent a good while trying to isolate an issue where Enpass was failing to start and looping through the startup. (It has been working without issue...).

Title: Bug Report / Missing Dependencies: Container loops/exits with Enpass v6.12.6+ (Wayland/XCB issues)

Environment:

• Container: ich777/enpass

• OS: Unraid

• Enpass Versions: v6.12.6.2255 and v6.12.6.2258

Symptoms: When starting the container, it enters a restart loop (Exit Code 0). The noVNC web interface starts, but the Enpass UI never appears. Because line 95 in /opt/scripts/start-server.sh suppresses standard error output (${DATA_DIR}/Enpass 2>/dev/null), the application crashes silently, making it appear as though the script simply reached EOF.

Root Causes Discovered: After executing the binary manually inside the container to unmask the stderr output, I tracked the crashes down to a few compounding issues:

1. Missing Shared Libraries: The current Debian base image is missing Qt/XCB dependencies required by recent Enpass builds. Running ldd and unmasking the crash logs revealed fatal errors for:

   • libOpenGL.so.0 -> requires apt-get install libopengl0

   • libxcb-cursor.so.0 -> requires apt-get install libxcb-cursor0

2. Wayland vs. X11 Shift: Upstream Enpass appears to be dropping X11 plugins in favor of Wayland in their latest builds. When the startup script downloads the newest version, it instantly crashes against the container’s TurboVNC/Fluxbox X11 display (:99).

3. Forced Version Overwrites: If a user manually rolls back the binary in their /appdata to a working X11-compatible version (like 2255), the start-server.sh script sees the version mismatch on the next boot and automatically overwrites it with the broken Wayland build.

Current Workaround: To get it running, I had to build a custom local image layer injecting libopengl0 and libxcb-cursor0, roll back the binary in my appdata to a working X11 build, and spoof the instv6.12.6.x file to trick the version checker so it wouldn't overwrite my working binary.

Feature/Fix Request:

• Could you add libopengl0 and libxcb-cursor0 to the base image dependencies?

• Is it possible to remove the 2>/dev/null redirection in the start-server.sh so future silent crashes are logged to the Unraid Docker console?

• Might need to look into an environment bridge for Wayland if Enpass permanently drops XCB support in future builds.

Edited September 23Sep 23 by dja

On 9/22/2026 at 11:17 PM, dja said:

@ich777 Forgive my AI generated report here, but I spent a good while trying to isolate an issue where Enpass was failing to start and looping through the startup. (It has been working without issue...).

Title: Bug Report / Missing Dependencies: Container loops/exits with Enpass v6.12.6+ (Wayland/XCB issues)

Environment:

• Container: ich777/enpass

• OS: Unraid

• Enpass Versions: v6.12.6.2255 and v6.12.6.2258

Symptoms: When starting the container, it enters a restart loop (Exit Code 0). The noVNC web interface starts, but the Enpass UI never appears. Because line 95 in /opt/scripts/start-server.sh suppresses standard error output (${DATA_DIR}/Enpass 2>/dev/null), the application crashes silently, making it appear as though the script simply reached EOF.

Root Causes Discovered: After executing the binary manually inside the container to unmask the stderr output, I tracked the crashes down to a few compounding issues:

1. Missing Shared Libraries: The current Debian base image is missing Qt/XCB dependencies required by recent Enpass builds. Running ldd and unmasking the crash logs revealed fatal errors for:

   • libOpenGL.so.0 -> requires apt-get install libopengl0

   • libxcb-cursor.so.0 -> requires apt-get install libxcb-cursor0

2. Wayland vs. X11 Shift: Upstream Enpass appears to be dropping X11 plugins in favor of Wayland in their latest builds. When the startup script downloads the newest version, it instantly crashes against the container’s TurboVNC/Fluxbox X11 display (:99).

3. Forced Version Overwrites: If a user manually rolls back the binary in their /appdata to a working X11-compatible version (like 2255), the start-server.sh script sees the version mismatch on the next boot and automatically overwrites it with the broken Wayland build.

Current Workaround: To get it running, I had to build a custom local image layer injecting libopengl0 and libxcb-cursor0, roll back the binary in my appdata to a working X11 build, and spoof the instv6.12.6.x file to trick the version checker so it wouldn't overwrite my working binary.

Feature/Fix Request:

• Could you add libopengl0 and libxcb-cursor0 to the base image dependencies?

• Is it possible to remove the 2>/dev/null redirection in the start-server.sh so future silent crashes are logged to the Unraid Docker console?

• Might need to look into an environment bridge for Wayland if Enpass permanently drops XCB support in future builds.

having the same issue here

On 9/22/2026 at 11:17 PM, dja said:

Forgive my AI generated report here

Sorry but no, I don't forgive such reports anymore. These are a mess and have too much information a human would never write.

However I'll drop the container since I don't support Wayland, you can use the old version but I'm not sure if there are old versions out there.