mkdir: can't create directory '/data/Config': Permission denied

[LawsonJohnson]

So I'm using a bind volume on my Synology NAS (I'm managing Docker with Portainer):

I get the error that the directory /data/Config can't be created.

Entrypoint | 2022-05-26 20:47:28 | [info] Installing Foundry Virtual Tabletop 9.269
Entrypoint | 2022-05-26 20:47:30 | [debug] Installation completed.
Entrypoint | 2022-05-26 20:47:30 | [info] Preserving release archive file in cache.
Entrypoint | 2022-05-26 20:47:30 | [debug] Patching GUI update and configuration messages.
Entrypoint | 2022-05-26 20:47:30 | [info] Setting data directory permissions.
Entrypoint | 2022-05-26 20:47:30 | [info] Not modifying existing installation license key.
Entrypoint | 2022-05-26 20:47:30 | [debug] Completed setting directory permissions.
Entrypoint | 2022-05-26 20:47:30 | [info] Starting launcher with uid:gid as foundry:foundry.
mkdir: can't create directory '/data/Config': Permission denied
Launcher | 2022-05-26 20:47:31 | [debug] Ensuring /data/Config directory exists.
Entrypoint | 2022-05-26 20:47:31 | [error] Launcher exited with error code: 1

The strange part is that not only is it created, it also contains the license file (whether I add it as an environment variable, or I let the login fetch it.

drwxrwxrwx foundry foundry  64 B  2022-05-26 16:07:00 🗁 #recycle
drwxrwxrwx foundry foundry  76 B  2022-05-26 16:36:46 🗁 .
drwxr-xr-x root    root    1.2 KB 2022-05-24 21:30:09 🗁 ..
drwxrwxrwx foundry foundry  24 B  2022-05-26 14:06:23 🗁 @eaDir
drwxrwxrwx foundry foundry  24 B  2022-05-26 16:37:15 🗁 Config
drwxrwxrwx foundry foundry  40 B  2022-05-26 16:10:17 🗁 container_cache
drwxrwxrwx foundry foundry  64 B  2022-05-26 15:31:58 🗁 ssl

My compose (redacted) is below, any ideas? I tried adding a Volume and tmpfs just for the /data/Config directory but had no luck with that either.

---
version: "3.8"

services:
  foundry:
    image: felddy/foundryvtt:latest
    hostname: ****
    init: true
    volumes:
      - type: bind
        source: /volume1/foundry_vtt
        target: /data

    environment:
      - FOUNDRY_USERNAME=****
      - FOUNDRY_PASSWORD=****
      - FOUNDRY_LICENSE_KEY=****
      - FOUNDRY_ADMIN_KEY=****
      - FOUNDRY_MINIFY_STATIC_FILES=true
      - FOUNDRY_SSL_CERT=./ssl/****.crt
      - FOUNDRY_SSL_KEY=./ssl/****.key
      - CONTAINER_VERBOSE=true

    ports:
      - target: 30000
        published: 30000
        protocol: tcp

[Llisandur]

I was having this same problem. I had the data folder in a separate shared folder from Docker. I managed to solve it by moving the data directory to inside the Docker shared folder. It seems to be a permissions issue with Docker manipulating a directory outside its own shared folder.

[ThePoetics]

Would it be possible for you to expand on that, @Llisandur? I'm seeing the same error as @LawsonJohnson when starting up Foundry this morning, though all the directories are 777'd. I haven't moved my installation and so I'm confused as to why Docker is now having an issue.

(current path for Foundry is /volume1/docker/Foundry/data with my other containers within /volume1/docker/ with no issue)

[ThePoetics]

Apologies for pinging @felddy directly but I don't know if the above posters are going to respond to a months-old thread :)

[felddy]

I'm sorry, but I do not have access to a Synology NAS to test. From what I can gather from previous discussions about Synology NAS bind mounts, they are limited to specific locations on the NAS. It seems like your bind mounts are in a "blessed" location as it has worked previously and matches what @LawsonJohnson posted.

I linked a couple of other discussions here that are relevant, as well as a post from Reddit that has a good explanation of Docker on Synology.

If this was my NAS, I think my next steps would be to:

• Examine all the logs I could find. This would include looking at dmesg for anything out of the ordinary.
• Investigate the usage of ACLs in the filesystem.
• Verify the Docker volume configuration and ensure the correct paths are used for the bind mounts.
• Check user and group IDs (UID and GID) and ensure they match the necessary permissions on the Synology NAS.
• Adjust file system permissions for the bind mount directories. (you did this 777)
• Try re-creating a new instance of the container with a new data bind mount.

If you figure this out please post what you found. I expect other users will hit this as well.

See:

• Guide for hosting foundryvtt-docker on a Synology NAS #265
• Question concerning Data storage on Synology #177
• https://www.reddit.com/r/synology/comments/k10bh1/comment/grdeppz/?utm_source=reddit&utm_medium=web2x&context=3

[LawsonJohnson]

@ThePoetics Hello! I set this up so long ago that I have little idea what the process was. However, I'm going to post my current tweaked docker compose here (with secrets redacted, of course). For reference, I'm using Portainer to manage it, but that shouldn't matter here.

---
version: "3.8"

services:
  foundry:
    image: felddy/foundryvtt:10
    hostname: foundry
    init: true
    # Prevents creation of additional network
    network_mode: bridge
    # Run an internal shell in the container (So I can hop in and debug as needed)
    tty: true
    
    # Run until it works (3 tries)
    deploy:
      restart_policy:
        condition: unless-stopped
        delay: 15s

    # The bind mount I made is a share created by Synology, but I recall having to tweak the file permissions manually (see the directory permissions below).
    volumes:
      - type: bind
        source: /volume1/FoundryVTT
        target: /data
      
    environment:
      - CONTAINER_VERBOSE=true # I like my debug info, thanks!
      - FOUNDRY_USERNAME=REDACTED
      - FOUNDRY_PASSWORD=REDACTED
      - FOUNDRY_ADMIN_KEY=REDACTED
      # Both IDs exist already on the server and files are 660 (directories 770)
      # Synology Admins ignore Linux file perms
      # Due to this ownership, the FoundryVTT Share is
      # innacessible from DSM and SMB, and presumably other "high-level" options
      # Note: at some point I fixed the above issue; I definitely can do this now
      - FOUNDRY_GID=65558 # Synology foundry group
      - FOUNDRY_UID=1045 # Synology foundry user
      - CONTAINER_PRESERVE_OWNER=/data/Data/assets
      - FOUNDRY_HOSTNAME=REDACTED.com
      - FOUNDRY_IP_DISCOVERY=false
      - FOUNDRY_LANGUAGE=en.core # Default, but may use with patches later
      - FOUNDRY_LOCAL_HOSTNAME=Whatever your local IP or hostname is
      - FOUNDRY_MINIFY_STATIC_FILES=true
      # - FOUNDRY_PROXY_PORT=
      # - FOUNDRY_PROXY_SSL=false
      # - FOUNDRY_ROUTE_PREFIX=
      - FOUNDRY_SSL_CERT=/data/ssl/REDACTED.crt
      - FOUNDRY_SSL_KEY=/data/ssl/REDACTED.key
      - FOUNDRY_WORLD=redacted
      - TIMEZONE=America/New_York
    ports:
      - target: 30000
        published: 30000
        protocol: tcp
        mode: host

SSH'ing into my Synology and looking at the directory permissions for /volume1/FoundryVTT I see:

d--x--s--- foundry foundry  22 B  2023-04-15 07:00:02 🗁 #recycle
drwxrwsr-x foundry foundry 144 B  2023-03-11 09:35:24 🗁 .
drwxr-xr-x root    root    1.1 KB 2023-03-11 09:34:47 🗁 ..
drwxrws--- foundry foundry  58 B  2023-04-20 01:00:01 🗁 @eaDir
drwxrws--- foundry foundry 124 B  2023-03-15 22:06:03 🗁 Config
drwxrws--- foundry foundry  84 B  2022-12-06 14:32:27 🗁 container_cache
drwxrws--- foundry foundry   0 B  2022-10-25 09:22:50 🗁 container_patches
drwxrwsr-x foundry foundry 178 B  2023-04-03 01:09:13 🗁 Data
drwxrws--- foundry foundry  36 B  2022-09-05 21:47:49 🗁 Logs
dr-xr-s--- foundry foundry  64 B  2022-09-05 22:04:03 🗁 ssl
.rw-rwS--- foundry foundry 207 B  2022-09-16 16:48:28 🗋 .stignore

I believe setting the setgid bit on the group permissions was relevant. In fact, after reviewing all this information I think that may have been what resolved the issue you're encountering.

Now for the shameful hack I had to do to fix issues with users adding files to the share directly (not from the Foundry interface) if I remember correctly. I have a scheduled task on the Synology that runs every minute to fix the file permissions, just a custom bash script bash "/volume1/System/Scripts/foundry_assets.sh" (you could locate this wherever this is just the folder I created in the Synology DSM interface to hold logs and scripts exported/used by DSM.

The actual script contents:

#!/usr/bin/env sh
foundry_assets="/volume1/FoundryVTT/Data/assets/"
chown -R foundry:foundry-assets "$foundry_assets"
chmod -R o-rwx "$foundry_assets"

Hopefully some of this info dump can help you with your issue or any future Synology permission fighting future readers have to commit; feel free to ask any follow-up clarifications if you'd like.

[ThePoetics]

Thank you very much, both of you, for the replies! I ended up fixing the issue last night by creating a new Foundry directory (within the docker path of /volume1/docker/) and moving my data over. I'm assuming it's something unique to do with Synology's implementation; I set both UID and GID on the original install to no effect, but now things are happily chugging along and I'm back to running games.

Thank you!

[Shubedobedo]

can you share you ntfs setting? I am running into the same issue. I find that I can make it work by changing my squash setting to no mapping then restarting my server. After that I need to go back into ntf setting and change it back to Map users to admin. Then it seems to work fine until I need to restart the server. SO janky!

[Rogger69]

Update for DSM 7 :
https://foundryvtt.wiki/en/setup/hosting/synology-with-docker