I would use the term "successfully" lightly. Here's a more specific example:
My file tree that I'm trying to duplicate has been mirrored between my C drive and FreeNAS. So, if I head to
and make something with content, like
, then I can look in
Code:
/media/Wisdom/Documents/Test
. However, what I'll find is
Code:
.syncthing.test.txt.tmp
. I need to tell my computer what to use when I'm opening it, and I can't just set some kind of global standard - it does this will every kind of file type I try to copy, from mp3s to pdfs to pngs. The upside is that once I use the right program, then the original contents of test.txt have been transferred over, it just takes some extra work to get there.
Using this example, we're looking at this:
Code:
root@syncthing_1:/ # ls -l /media/Wisdom/Documents/Test
total 1
-rwxrwxr-x+ 1 syncthing Wisdom 0 May 23 00:04 .stfolder
-rwxrwxr-x+ 1 syncthing Wisdom 19 May 23 00:04 .syncthing.test.txt.tmp
root@syncthing_1:/ #
When I looked in syncthing, after pairing the two folders together, despite update the .tmp file, syncthing still thinks that it's out of date (and realistically, it is, since it's not a complete copy of the original). However, looking at the error syncthing is reporting, it says specifically
Code:
chmod /media/Wisdom/Documents/Test/.syncthing.test.txt.tmp: operation not permitted
If I manually try to chmod anything inside that folder, even after elevating (in particular, as you described earlier in this thread for the previous user), I get a whole pile of operation not permitted errors. To this end, I've tried toggling permit sudo permissions for different users and groups and it hasn't seen to make a difference, though I suspect that may be due to changing the permissions on the FreeNAS-facing side of the group interface, rather than actually changing how the group behaves within the jail.