voyager12

Definitely a file permissions issue. Google how to fix file permissions issues in Linux. I've already given you the command to use but it might be that the foundry user is a non-standard UID/GID.

You'll need to provide more specific paths but just checking my installation, it looks like the top level folder that the file picker provides is the Data directory within the container path. So you'll need to make sure your asset folder is at a non-occupied location within /mnt/user/<foundry_folder>/Data/<unique_name>. This is called a recursive mount and is documented here: https://docs.docker.com/engine/storage/bind-mounts/#recursive-mounts. However, I do want to make one caveat if I can guess why you're trying to do this. If you're doing this because you want to share assets between different versions of foundry, then be cautious. Assets are not guaranteed to be backwards compatible between asset versions so if you create assets in v13 foundry in that folder and try to use it in a different instance of foundry (say in V12), you may run into compatibility issues. I originally thought I'd design my set up this way but ran into those issues. If you want to share assets between instances, it's usually more robust to just copy the data over manually from the Unraid command line, copying from older foundry version to newer, and allow the newer version to update the assets to be compatible with its version. That way they have separate copies and can edit them without issues.

It does but currently, container updates don't update your unRAID template which is the one that provides the image. I just updated the image url manually myself as the old one is no longer accessible and wasn't provided by the template owner anyways.

Check the container logs. If I had to guess, you're having the same permission problems I just posted about. I would highly recommend people not using the release tag and using a tag of the major version they want to use otherwise you'll keep having problems similar to this with major releases without much warning when your container updates.

So I think your So you've definitely updated to v13 which has the permission changes as mentioned in that link I sent a few comments back: https://github.com/felddy/foundryvtt-docker/releases/tag/v13.340.0. I would recommend pinning to a major version tag by setting repository field to felddy/foundryvtt:13 and keeping that last number to the major version you want to use. Changing that number is not backwards compatible so only do it intentionally. To get it to work with v13, you'll need to run chown -R 1000:1000 /mnt/user/<path_to_foundry_data_folder>. Or otherwise change the docker user container to match the data.

In your unraid template, what is the text in the "Repository" field? The tag is what is after the colon.

What docker tag are you using in your template? If it's latest or release, then it will auto upgrade major versions.

Did you update from v12 to v13? If so, it's because the permission handling is different now. See https://github.com/felddy/foundryvtt-docker/releases/tag/v13.341.0. let me know if that doesn't help.

From a quick Google search: https://github.com/felddy/foundryvtt-docker/discussions/159

That link at the end of the logs tells you what to do. You need to fix the share permissions.

Hey, I don't think FOUNDRY_VERSION should be part of the template, according to the author of the docker, we shouldn't be setting FOUNDRY_VERSION as it is set by the container. Specifying the foundry version you want should be set by the docker tag, not the environment variable so you get a node version to match the foundry version that have been tested together. I removed the argument from my template and I thought I'd post it here since I saw others getting errors related to this.

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>

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

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.

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.

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?

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?

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?

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?

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.

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.

Ah, this is the answer: https://forums.unraid.net/topic/44109-support-binhex-delugevpn/?do=findComment&comment=952189

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:

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.