voyager12

Members
  • Posts

    16
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

voyager12's Achievements

Noob

Noob (1/14)

2

Reputation

1

Community Answers

  1. One solution is to simply stop the conflicting container. It requires you to know that the reason it is hanging is a GPU access conflict and to know which container but it works for me. You can do that with: docker container stop <name-of-container>
  2. I just reinvestigated this and it looks like this was fixed upstream. Earlier I mentioned the github.com/limetech/dynamix.git repo and that does indeed look to be an old version of the package. Limetech currently uses: github.com/limetech/webui for their repo and in that repo I found this commit: https://github.com/limetech/webgui/commit/d57affd193d4feef700421ce4e527ee3a1a33e18 which looks to have fixed the issue. I don't think this commit was deployed on Unraid 10.3 but it's likely in 11.0 or 11.1. I'll have to test it out when I decided to upgrade my Unraid version. Edit: can confirm that this is fixed in Unraid 6.11.1 at least
  3. I'm sorry it's taken me so long to respond. I intended to try to publish my fix; however, my server is currently down for maintenance to fix unrelated problems and so I don't currently have access to what I did. I will publish what I did once it is back up and running. As a summary, I just use a user script to modify the relevant php file to patch the fix I need. Ideally I could make a plugin that does this to make it easier to distribute but we'll see if I prioritize that.
  4. I set my primary graphics card to onboard for both boards and am still not able to get /dev/dri to show up. As a side note, when I add an nvidia graphics card and install the drivers, it shows up at the /dev/dri spot instead, so it seems that I am not setting the iGPU to be primary correctly. But the setting is doing something because the terminal does display on the integrated graphics HDMI port.
  5. I just tried with the ASRock z590 Pro4 and that doesn't work either. Am I missing something? Does it not work with the Z590 chipset?
  6. So I was able to fix my problem. The WebUI link generation is in /usr/local/emhttp/plugins/dynamix.docker.manager/include/DockerClient.php. I just wrote a user script that patches the link generation that just allows a manual, user-specified WebUI if all other methods fail. I was going to try to put in a PR to contribute the fix upstream at github.com/limetech/dynamix.git, but that repo hasn't been touched since 2016. Also, the version there is different from the version on 6.9.2. I'm not sure which is more up-to-date as I don't have the date on the version in 6.9.2, though interestingly enough, the one on github looks like it wouldn't have this problem. Did limetech take the code to closed source or is there another place that the code is hosted?
  7. So it's not a template where the IP and ports are replaced? If that's the case, then what's the point of the input field in the template scheme? What can you change about it?
  8. Then why does the manual specifying of the URL not work? If I remove the bracketed parts and put in exactly what it should use, why does that not work?
  9. I'm trying to get a docker container to route its internet traffic through another docker container exactly as is described in this SpaceinvaderOne video: However, when I follow the video, all containers that are using the vpn container lose their "WebUI" button on the docker tag of Unraid. The WebUI is still accessible by typing in the URL manually into my browser, but I'm trying to figure out how to get the buttons back. To summarize the main points of the video: 1. I specify --net=container:<container-name> on all containers that I want to route through another container 2. the vpn container must expose the ports that the sub-containers are publishing on to be able to access them 3. The vpn container must allow local connections on its iptables. I've done this manually and know it works because I can access the webui by manually typing in the URL of the container (with port) and it resolves. The default WebUI values that I see in the sub-container's docker templates are along the lines of http://[IP]:[PORT:<WebUIPort>] where <WebUIPort> is replaced with the container's (not necessarily the host mapping that you specify in the template) published port. I've tried these variations: 1. http://<ip-of-unraid-server>:<external-accessible-port-of-container> 2. http://<ip-of-unraid-server>:<internal-port-of-container> 2. http://[IP]:[PORT:<internal-container-port>]/ 3. http://[IP]:[PORT:<external-accessible-port-of-container>]/ Where all angle brackets are replaced with their literals by me and not unraid.
  10. I'm still struggling to get the /dev/dri device to show up. Does this depend on a feature of the motherboard that I am not aware of? I haven't even tried the plex side because the device does not exist and intel_gpu_top -L returns no devices. Specs: unraid 6.9.2 CPU: intel i7-11700K Motherboard: MSI Z590-A Pro with iGPU enabled in bios (On msi it's called IGD and it makes your iGPU your primary. I assume that's all that is needed). Also HVM and IOMMU is enabled. intel_gpu_top is installed /boot/config/modprobe.d/i915.conf file created Not sure how important this will be for my set up but I'm hoping to add a 4k movie soon and I want to be able to watch it on different devices.
  11. Ah, this is the answer: https://forums.unraid.net/topic/44109-support-binhex-delugevpn/?do=findComment&comment=952189
  12. I think the reason we were trying to avoid your method is that it can potentially leak past vpn connections. My understanding is that using a proxy is not a secure as using a vpn connection. Also, the reference video that I was using was Spaceinvaderone's:
  13. I'm having the same problem. I had it working before 6.9 but ever since I updated, my set up stopped working and I can no longer access the web UIs. Your title might be a little misleading though because the dockers are correctly being routed through the VPN, just the web UIs are not accessible. Edit: I tried reverting to 6.8.3 but the problem persists... Edit2: I tried curling the web gui at different levels starting within the container, from the container its networked to, from host os (unraid), and then from a LAN computer. All worked except the final one. This tells me that perhaps the port is not being opened properly on the right network driver? I should note that I used localhost for each one except for the final one. Using the host os LAN ip from the host os does fail as well.
  14. Following a specific issue in the Application Support section is hard for the more popular apps. Here's the current workflow: I have a bug. I search for the bug on the support forums. I find a potential match. I go to that post. I then want to follow that post to see how others ave responded to it and how the originally poster posts their progress. If other people are posting their own issues in between posts about the issue I'm following, I have to read every single post to determine if it is about the issue I'm talking about. This is relatively quick per post if the user quotes the post they are responding about but not if they don't Even if they do quote the post they are responding about, it is still a long task to determine if every post in between the post I care about and future posts are relevant. In computer science terms, this is like an array that holds several categories of topics and has to be re-indexed every time you want to find a chain of logic. Proposition: Replies appear as sub-comments in a thread. Ex. Reddit replies to a thread. Explanation: 1. Originally I was going to suggest that the forum should model format exactly like Reddit but this thread suggests that that makes it harder for application supporters to find relevant posts and it makes it easier for support requests to start a redundant thread if they don't know where to post. 2. To compromise the above, I propose that users still cannot create new threads, but instead, they can reply to posts and their posts are displayed as a branch of the post they are replying to. For example: Take this image taken from Reddit about the new spaceinvaderone video about migrating to SWAG: Here I'll define some terms in context of this picture: Thread: the post about the new spaceinvaderone video entitled "New Spaceinvader One Video: How to Migrate from Letsencrypt to the New Swag Container" Comment: Valpo13's comment starting with "Thanks /u/spaceinvaderone. I think I can speak behalf of everyone..." Reply: Spaceinvaderone's reply starting with "Thankyou very much /u/Valpo13 for your message..." In my proposition for this forum, the matching definitions would be: Thread: Current definition of threads/topics in Unraid forums. For Application Support, this would be the thread that maps to a specific application support thread. Comment: An original issue or request for support raised by a user. Reply: All posts that relate to a given comment and are initiated by a reply button. Note: the reply button would not replace the quote button but would be an addition. Arguments for why this would be beneficial: 1. It immediately becomes easier to follow a specific issue that a user posts and I can quickly identify if it was resolved and how it was resolved. 2. Less text on a page. Quoting for the purposes of maintaining documentation on who you're replying to becomes unnecessary. Less text make it easier to a user/app author to parse posts and threads. 3. Maintains the ease of finding relevant issues for app supporters (and users) because all app support is still part of a single thread.