I want help you with development, but I am not a programmer, so I can help you only with ideas and bug-testing 
I hope that some others will post any patches for this featureā¦
Iād like to help, but i am not fimiliar with go. Is there a developer who wants to help us with this problem?
Great opportunity to get familiar.
1 Like
No way man 
There is no time to lern a new language. I hope an other developer will fix this problem. Pershaps in the next winter is enough time, to lern Go and add this feature.
Thanks for you work!
1 Like
Any progress in this direction? Itās quite anoying with no ownersync permissions. I have all the time again problems, because some files have ownership āadminā and not āUser1ā, oder an other 
So if this would be fixed, it would be great. Iām only a cpp-proger, no knowledge of goso far
Jakobās original thinking is this is (I believe) correct. Permissions and users/groups are a āratās nestā, haha. I 100% agree on that.
Itās surprising itās as far along as it already is.
The elephant in the room is the filesystem ā especially for mobile. There is no standard filesystem across Android ā thereās ext4, yaffs, Samsungās RFS, etc. To implement ownership youād need to have a rooted phone. Most ppl donāt have that.
Permissions might be the same on Linux whether you run ext3, ext4, xfs, zfs, etc , but not if you use ntfs, fat16, fat32, vfat, etc. So thereās no standard for filesystems between Unix flavors, Mac OS X, and Windows. Nor is there a standard API layer.
Well, unless you count FUSE, and I know everyone hates that , soā¦ Plus I donāt think FUSE would be easy to get working on mobile.
I donāt know, how it is in go, but in cpp under linux one way would be to use stat() to get the uid of a file and then getpwuid() to get the username as a string. I think I used it once and it worked also for mac-systems.
And for a Windows-system itās done like explained here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa446629(v=vs.85).aspx
Iāve researched a litle bit for golang:
Maybe you could implement it firstli for unix systems only? For other systems it will stay as it was until now.
To be clear, Iām not going to implement this. Someone else is welcome to of course, and itāll be integrated if itās not an unmaintainable mess and doesnāt seem to be a rabbit hole of future issues.
Note that any implementation will also need to take a serious look at the fact that this implies running as a user with elevated privileges and any risks that carries with it.
To participate to this discussion, without an authentication and authorization mechanism, syncthing is for personal usage and for exchanging documents with friends, family or small teams. Iāve looked a bit and found a couple of developments in go.
Iāve had just now an other idea!
Maybe easier than sync Permissions and owners would be the possibility to set in the folder-settings in syncthing the owner and permissions. So when you run syncthing as root, you can run it for different users on the same machine, without running severel instances of syncthing for different users. That would be much more efficient, specially on an ARM-Processor.
This option would be really cool
Running syncthing as root has quite serious security implications, as @calmh mentioned. It means that everyone who has access to the Syncthing REST API / web GUI (either because a password wasnāt set, or through carelessness / a 0day) can instruct Syncthing to read/write any file on the filesystem. Syncthing is effectively turned into a nice little rootkit.
For this reason, I doubt Syncthing will ever recommend users run it as root, or implement a feature which requires running Syncthing as root.
Hm, so there is no way around severel Syncthing instances on the same system?
Remember that having several Syncthing instances means that each user can have their own configuration, which they can manage without affecting other users.
Yes, thats thrue, but most NASās has weak performance and have already with one instance a lot to do.
Why do you have multiple system users on a NAS?
Its a QNap-NAS and there are for each user (family member) an account. So each user stores his data on the nas and cant see the datas from the other users. And they can embedd there ādriveā into the filebrowser on windows, mac etc. So they can work on it as an local drive. And the idea with syncthing is to sync the data also over the internet, when they are in the university ect.
That use-case sounds like you definitely want separate syncthing instances per-user, otherwise every user will sync all the data from all the users onto their own systems.
Assuming that the users will be able to elevate permissions on their own local machines, they will obviously be able to bypass any user / group permissions.
Sync file ownership most needed not for end users, but for system administrators in corporate area. For example, I need 2-side sync /home folder in about 20 computers, with about 50 users. All computers have same user/group list (using shared ldap user list), so all that I want is to keep uid/gid of files when I do sync.
Running about 50 clients from each user will eat all memory and cpu, this is bad solution.
So the good solution is run syncthing as root with sync uid/gid feature.
I understand that this will be some potential security breach with this mode, but if some hole will be found, it will work for single user instance too, so it must be fixed for all users, not only for root mode only.