You don’t have to execute anything within Docker container, this is already secured by the Docker image config as such, as I mentioned on the screenshots.
Eg. just by following configuration I mentioned above, when CHECKING my mounts on the container :
Btw thanks for pointing out config - I just tested it with /var/syncthing outside of Docker on my NAS and seems to be working fine so far (updated HowTo) (…and updated HyperBackup to include this directory in my backups 
)
It seems e.g. photosync is a folder inside of the container. Is possible to see the content and size?
The fact that the data is then duplicated due to the mount path (in the mount path of the container and in the file system) is not a solution for larger environments, as this may even exceed the storage space.
In your case you have “photosync” in the root path of the container and then all files in it, as in “photo” and thus twice. And only because these are then in the container you have access to them via Syncthing Docker and can sync. However, you don’t have direct access to the file system via Syncthing, only indirectly via the container.
I don’t see how this duplication can be avoided.
…there is no duplication, if you think otherwise please provide proof first.
What is e.g. inside of photosync? Is empty? On my side such folders not empty or 0.
I come back to the above because you wanted proof. Similar to your case, I assigned a server folder to a mount path “Syncthing-Docker” in the first line for a test:
This is located in the root directory and I connected it in the GUI
Inside of the Container it looks as follow:
In that directory is the same content as in the filesystem
And that is, what I mean, I have the same content in double.
I do not use Synology packages but I assume this is a bind mount. Docker mounts the local folder inside the container so it can access it.
There is no duplication in this case, the same data is accessable through both paths.
Edit: more info https://docs.docker.com/storage/bind-mounts/
You can easily test by allocating a reasonably large file in one of the shared folders and testing available space.
Yep,as I pointed out 2d ago 
If Docker is chosen as the path forward, some Synology NAS hardware which previously supported Syncthing will be left out. The DS420j I run does not support Docker.
This is one aspect regarding the Docker platform. Docker and its images and containers can only be installed on models from a certain performance level. However, also the SPK is not fully available for all Synology platforms either.
However, this is not the only limit to the Syncthing Docker variant.
Another aspect is performance. My first tests have shown that the performance is lower, so that the environments cannot be as large as we know from native installations if the processes are supposed to be smooth in the same way.
In any case, it would only be logical if the Syncthing-SPK for Synology also runs on DSM 7.
Just for information, today I got the follow message from Synology development:
It has been quite a while since we last disucss about the release for DSM7, and I’m wondering if everything is going well : ). We predict that most of our users may gradually upgrade their DSM to the latest version, and hope that their user experience will be the same as DSM6. Therefore, we hope that the Syncthing package may be available on DSM7 before the official release date, that may likely fall on 2021 Q2. If you have any questions during developing the package, or any questions about the development guide, please don’t hesitate to contact me.
Thanks for your support as always : )
P.S. The attached is a revised and updated developer guide that has fixed several documentation bugs.
So it means the planning is latest end of june 2021 zu release Final of Synology DSM 7. For information also the current developer guide DSM7_developer-guide-ex.pdf.
Just as information for developer a message from Synology I have received:
This is a kind reminder on the support of your package on DSM7.
As our release date for DSM7 Official will likely fall on 2021Q2, most users will automatically/manually upgrade to the stable version for DSM7. Therefore, to ensure that users for your package may keep on using the package; therefore, we hope that you could provide your package by 2021/03/26.
We usually run second reviews for submitted package, the x86_64 automation test for checking the package framework and the manual test performed by our QC team, which is meant for checking the basic functionality of the package. Our team runs auto review twice a day, but only runs manual review once a month (usually on the last week of each month). Most of developers failed the first review, either they are adept to building Synology package or not.
Hence, I would recommend you to provide the package as soon as possible, so that we can run the review earlier. If the package cannot be presented by the official release of it, we may receive support tickets from users and we may then take certain measures (such as temporarily/permanently unsupported announcement on release notes & documents) to prevent such issue.
If you have any questions during development, or confronted any issues, please don’t hesitate to let me know, thanks [image]
P.S. If possible, please kindly provide the ETA for providing the first package on DSM7 to us, so that I can predict the possible release date for the package, thanks!
Sincerely,
Vanessa Huang | Product Specialist
Synology Inc.
+886-2-2955-1814 #8104
www.synology.com
vanessah@synology.com
Hello everyone. I’m new around here.
I’ve been using Syncthing in Docker for a few days and it works as expected, but there is a problem with Synology’s own integration with Docker volumes binding: any file that Syncthing introduces will be invisible to Synology Drive and its versioning system, as when changing files in those folders from the container, the indexing is not updated as it happens with other ways.
I’ve tried everything, running the command “synoindex -R all” … but nothing works to get the files to show up in Drive view, they can only be seen in File Station.
I’m really a bit desperate on this matter. For the moment I am going to link Syncthing to folders outside of Drive, losing its advantages of versioning and client applications, until I find another solution.
BTW, thanks for this amazing software. I will try to learn Go to be able to do my bit 
Note: All this happens with DSM 6.2, I don’t know if with DSM 7 they have improved this aspect of Docker. As soon as I have time I test in a virtual machine.
I use Drive on all Synology NAS, currently DSM version 6.2.4. However, I do not use Drive to synchronize items, but primarily to share files with others. For this I also use ownCloud or nextCloud, depending other things.
All folders I manage with Syncthing are also activated or integrated in the tools mentioned above and all the tools are indexing the content. It all works smoothly. Some time ago I even had Resilio running in parallel, which also had no negative impact (Resilio is still running and still indexing, but is currently not involved active sync processes).
Therefore, is the question, are such issues happen when Drive is integrated and indexing contents, or only during synchronizing processes? If so, it might be an ACL issue that should be reviewed.
The problems occur as soon as a file is introduced into the Drive folder by Syncthing. Synology system doesn’t index it, I can’t even see them the next day. The only thing that seems to work (and I’m not entirely sure) is restarting the Drive app as it forces a reindex of the entire database.
I have used Docker correctly mapping the PUID environment variable with the Drive user and from SSH I can see that the files entered from Syncthing and the ones I upload from the Drive web have exactly the same permissions, owner and group.
With Resilio Sync it works fine when installed from the package, but with Docker it has the same problem. It appears that files changed from a Docker container do not raise the event that Synology expects to index into its database.
I have been contacting Synology on that (not due to the Drive by Photos), explaining them the situation … Anyway, if ever some official solution will come, I’m using following script :
/var/packages/SynologyPhotos/target/usr/bin/synofoto-bin-index-tool -t basic_reindex -i /volume1/photo/
(maybe similar one exists for Drive)
#/bin/sh
find “/volume1/photo/SYNC_SUBFOLDDER/” -not -ipath “eaDir” -not -ipath “stign” -not -ipath “trash” -not -ipath “thumb” -not -ipath “stfold” -not -ipath “SYNO” -mmin -60 -print | while read filename; do
touch -m -d “$(date -R -r “$filename”)” “$filename”.
done
Far from ideal but it works for me, hopefully it will for you as well.
With the Docker installation I make currently tests and I have no experience regarding my daily work, since I only use the native package installations for my daily works.
If using of different PGID and PUID regarding native package and Docker image make the difference, I dont know. I use for my Docker images a separate user and group, which is also stored in Synology DSM and this user and group have the same permissions is given for the native packages.
Regarding the Indexing, this means indexing of the content and maybe is to be good to activate Universal Search
@shaarkys thanks for the workaround.
I am a little scared to apply the second script to folders with photos, since the touch command modifies the modification dates of the files. I understand that you use the -d parameter to take the same date that it had, but with any errors … Anyway, it is appreciated.
I will investigate if there is a specific command for Drive like that for Photos as you comment.
@Andy thank you also for your attempt to help. Unfortunately, this Universal Search is the one that is activated by default for Drive folders and it is what fails to detect the changes.
I understand that you have not had big problems because as you say, you use the native packages. This problem with Docker seems to be an old friend, as I have found a repository with a patch to this problem created 5 years ago:
I was just commenting on it in this thread, because if there is finally no package for Syncthing outside of Docker for DSM 7, please note that this problem may not have an easy fix, unless Synology changes its implementation of Docker volume binding.
You don’t need to (nor should you) rely on modification date on photos, any more than with any other file. The date it was taken on is written in the pictures metadata, completely independent from the modification time.
Using it for 2 months already, no issues at all.
