Jump to content

Rozella

Members
  • Posts

    4
  • Joined

  • Last visited

Everything posted by Rozella

  1. Tmux is no longer working since updating UD Preclear to 2024.04.23 – it produces the following error: tmux: /lib64/libm.so.6: version `GLIBC_2.38' not found (required by tmux) tmux: /lib64/libc.so.6: version `GLIBC_2.38' not found (required by tmux) Running the command /lib64/libc.so.6 shows that version 2.37 is installed, which is obviously a version behind the version mentioned in the error. I'm on version 6.12.8 of Unraid.
  2. I found this post after describing the same issue in a reply on another post. I'm glad to know I'm not the only one. It would be nice to get some support feedback from someone soon.
  3. I have a related issue and would appreciate some help. I'm running some containers through a VPN container (by setting network type to "None", adding the extra parameter "--net=container:OpenVPN-AIO-Client" and then adding the ports to the VPN container). As I would expect, the containers with no network of their own do not show any port mappings: However, if I add a new container or update an existing container with network type "bridge", the port mappings for that container get replicated to all of the containers using the OpenVPN-AIO-Client container's network – e.g. the screenshot below shows what has happened after updating the binhex-krusader container – its port mappings are now showing for transmission and JDownloader2: This isn't specific to binhex-krusader – if I'd chosen to update a different container with the network type "bridge", that container's port mappings would have been replicated to the containers using the OpenVPN-AIO-Client container's network. As far as I can tell, this doesn't stop the transmission or JDownloader2 WebUIs from working on their assigned ports (9091 and 5800 respectively), and the binhex-krusader WebUI loads at port 6080, but presumably this port mapping replication should not be happening. If I force update transmission and/or JDownloader 2, this removes the replicated ports so things are back to looking like the first screenshot, but the issue will occur again the next time any other container with the network type "bridge" is added or updated. Does anyone know why this is happening?
×
×
  • Create New...