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.