Docker syncthing volume mapping errors

In the "Compose Files" section of the compose plugin, should the "Owner" and "Group of directories and files" be left as root?

I've been reconfiguring docker, clearing out old folders and settings on my OMV installation, and going through the OMV 7 Docker guide here, setting up as per section 2.2, pretty much starting from scratch because I had a disk failure.

I've kept the appuser user I had previously set up, which I'm using in the compose files.

I've made a syncthing container which is up and running, but I'm having some permissions issues with the sync folders. The folders it's creating seem to be owned by root with group root. Tbh I might just try changing the "Owner" and "Group" setting in the "Compose Files" section to "appuser" and see what happens.

Watch this space...

Syncthing is still complaining about folder creation. I vaguely remember from the first time I set it up (back when OMV was using Portainer (it worked for me back then so I'm clearly forgetting something) that there was a step where appuser was given ownership of the data folder.

Here's what syncthing is telling me when I try and add a folder to it.

Quote

2026-03-05 19:26:38: Failed to create folder marker (folder.id=53qoh-lqfau folder.type=sendreceive error="mkdir /data1/.stfolder: permission denied" log.pkg=model) 2026-03-05 19:26:38: Failed initial scan (error="folder marker missing (this indicates potential data loss, search docs/forum to get information about how to proceed)" folder.id=53qoh-lqfau folder.type=sendreceive log.pkg=model)

Quote from erbsenzaehler

If you use the linuxserver/syncthing image as described in the guide (here), the files should be owned by appuser:users. If you get more problems not with file owner and group but with permissions for the group, then try adding UMASK to the environment variables in the compose files.

Code

      - UMASK=002 #make files be 664, dirs be 775

Think about upgrading to OMV8 as well.

I'll try the - UMASK=002 line

I will definitely be upgrading to OMV 8 at some point.

Quote from erbsenzaehler

Can you share you compose file and the ownership of the path that is translated to data1 in the compose file under volumes?

In OMV I have a user "appuser" with UID 1002 and GID 100

I have a shared folder in my RAID pool called "Data" with "appuser" having RW permissions

/DATA is a symlink to /srv/dev-disk-by-uuid-35a47e11-1aa8-4377-95c9-152c61c299e8/Data which currently has the following attibutes when viewed in CLI:

drwxrwsr-x+ 1 appuser users 128 Mar 5 20:30 Data

Global Env looks like this:

APPUSER_PUID=1002
APPUSER_PGID=100
TIME_ZONE_VALUE=Europe/London

Compose looks like this:

# https://hub.docker.com/r/linuxserver/syncthing
services:
syncthing:
image: lscr.io/linuxserver/syncthing:latest
container_name: syncthing
hostname: syncthing #optional
environment:
- PUID=${APPUSER_PUID}
- PGID=${APPUSER_PGID}
- TZ=${TIME_ZONE_VALUE}
volumes:
- /SSD/config/Syncthing:/config
- /DATA/documents/sync_data1:/data1
- /DATA/documents/sync_data2:/data2
ports:
- 8384:8384
- 22000:22000/tcp
- 22000:22000/udp
- 21027:21027/udp
restart: unless-stopped
###########################
# This compose file is customized following the document: "Docker in OMV" from the OMV-Extras wiki.
# Adapt it to your server if the configuration is different.
# https://wiki.omv-extras.org/doku.php?id=omv7:docker_in_omv
###########################

When I start the container with "Up" it seems go smoothly.

export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LC_ALL=C.UTF-8; export LANGUAGE=; docker compose --file '/srv/dev-disk-by-uuid-fbcaa74e-31eb-4cb8-ada0-5731db9f01a4/dockerappdata/Syncthing/Syncthing.yml' --file "/srv/dev-disk-by-uuid-fbcaa74e-31eb-4cb8-ada0-5731db9f01a4/dockerappdata/Syncthing/compose.override.yml" --env-file '/srv/dev-disk-by-uuid-fbcaa74e-31eb-4cb8-ada0-5731db9f01a4/dockerappdata/global.env' --env-file '/srv/dev-disk-by-uuid-fbcaa74e-31eb-4cb8-ada0-5731db9f01a4/dockerappdata/Syncthing/Syncthing.env' up -d 2>&1
 Container syncthing Starting Container syncthing Started 
END OF LINE

The following folders are created:

Under /srv/dev-disk-by-uuid-35a47e11-1aa8-4377-95c9-152c61c299e8/Data

drwxr-sr-x+ 1 root root 40 Mar 5 21:52 documents

Under /srv/dev-disk-by-uuid-35a47e11-1aa8-4377-95c9-152c61c299e8/Data/documents

drwxr-sr-x+ 1 root root 0 Mar 5 21:52 sync_data1

drwxr-sr-x+ 1 root root 0 Mar 5 21:52 sync_data2

When I try and add /data1 to syncthing I get the following error:

Quote

2026-03-05 21:57:45: Failed to create folder marker (folder.id=dqzj9-qvkmo folder.type=sendreceive error="mkdir /data1/.stfolder: permission denied" log.pkg=model) 2026-03-05 21:57:45: Failed initial scan (error="folder marker missing (this indicates potential data loss, search docs/forum to get information about how to proceed)" folder.id=dqzj9-qvkmo folder.type=sendreceive log.pkg=model)

Quote from erbsenzaehler

Did you try deleting all files and starting from scratch again after switching to appuser:users? In my setup (similar to yours without symlinks) the dir mapped to /data1 is owned by root:users with drwxrwsr-x+ and I don't get any problems in docker log.

I have deleted everything to do with syncthing in docker and tried to re-up the compose file. It's possible I've missed something though. As I no longer have any containers in use I might try deleting everything and uninstalling/installing the compose plugin and start from scratch.

Quite a lot of head scratching today. But I think I have fixed it with the resetperms plugin. Thanks for your assistance.

I spoke too soon.

I'm not sure if I'm having a permissions problem or if the mapping isn't working properly. I think some realtime log analysis might help, but the OMV diagnostics logs are timing out on me.

What logs should I be looking at to try and see what's actually happening when the syncthing container tries to write to a directory? I've found Dozzle for looking at the output of the container's logs.

I got it working but it required changing ownership of all the folders the syncthing container creates to appuser:users via the command line.

I don't know if that's what I'm supposed to be doing but I'm going with it for now.