Hello,I have two cetos server,one is A,the other is B. I want to make A and B synchronized. I am sure A and B’s communication is ok. I have synchronize files betwween A and B successfully using the default file Sync. But,After I changed the file,It’s failed. please see pictures for detalis. By the way,I run syncthing by www:www.
I think you’ve answered your own question, syncthing can’t write files it doesn’t own. Syncthing is running as www-data, and files are owned by root.
This is basic linux 101, if you don’t understand this, I suggest you learn about linux before you try and use it.
I thought the problem may be the owner of the file, but before I asked you, I had already tested it
server A: the Folder Path is:/home/www/Sync/ root:root 777 I created a file named “heng.txt” by root(test.txt root:root 644),and a folder named “heng”(heng root:root 755) I run syncthing by www
so,syncthing only can read “heng.txt”,and can read and execute “heng”. On your opinion,syncthing can not synchronize “heng.txt” and “heng”. But ,the fact is sycnthing can. You can check it on the basis of my attachments.
The problem is syncthing can synchronize when I tested which the number of files is not so many,but it will fail when the number of files is many. Tank you ,and forgive my poor English.
you can know “syncthing is run by www” from the synchronized file’s owner.
Yes, syncthing can read files owned by root, which is why you think it works, but it cannot write to those files, which is the reason you see failures. Changing permissions, modification timestamps or other metadata (not data) on the files needs write access, hence ownership and user that runs syncthing needs to be the same everywhere.
Read about linux file permissions as you are clearly missing the point and just making your self confused by testing things that don’t actually explain the problem.
Thank you for your answer.
You opinion is: syncthing is run by www,the file’s owner is root.so syncthing can not write to file.
Although I don’t know the working principle of synthing,but syncthing really can write to file on the condition above.
server A: the Folder Path is:/home/www/Sync/ root:root 777 I created a file named “heng.txt” by root(heng.txt root:root 644) “heng.txt” is synchronized to server B. It becomes heng.txt www:www 644 on server B.
I edited heng.txt on server B,On your opinion,the content can not synchronized to server A.Because A’s heng.txt is owened by root. But ,the truth is It can.
You are either running these commands as root or potentially one side runs syncthing as root, hence why it works one way but not the other way
I am sorry,I can not get your point.Could you please explain it in detail.
Exactly, and you run your test commands as root as say that it works. It works if you run it as root, but syncthing runs as www, so the commands would fail if you ran then as www.
Your issue is nothing todo with syncthing but generic understanding of linux permissions, so as I’ve suggested go read about it. This is not the right forum for linux support/education.
So ,your opinion becomes I ran my commands as root may be the problem.
But,I will say you are wrong again.
I ran my commands as www,It can success again.But it will fail when the file is many.
I want to say I not asking for linux support.
It is very impolite that you say “read about linux” again and again.
I test your methond very carefully and show you the picture about how I did it.You just queried
my linux ability.
May be my linux ability is not as good as you,but It’s obviously the problem is not permission.
If you can not stop telling to read about linux,please do not replay again.
Can you confirm that after syncing heng.txt it is now owned by www:www?
I think there are two problems to understand this: Firstly, Syncthing does not update files in place. So while a file with 777 permission can be written to by anyone, that’s not what happens. Syncthing will create a temporary file with the new contents and replace the old file. Secondly deletion/creation of a file is not governed by its owner/permissions, but those of the parent directory. So Syncthing running as www can remove a file owned by root in your scenario, as your parent directory has 777 permissions (most importantly/notably, the o+w permission).
So you have set up a very specific testing scenario, where everything works out (even though the change of ownership isn’t likely desirable). In a real scenario, it doesn’t work, as you usually don’t have 777 dirs and even if you did, you probably don’t want files changing ownership due to syncing. In practice, only use Syncthing to manage files owned by the same user as Syncthing is running as.
Maybe retry with Syncthing now that you’ve fixed the permissions. Note that Syncthing creates temp files and needs access to the directory and not just the files. It looks from your screenshot like this would work.
Note also that there me by other restrictions imposed by systemd, selinux, etc. If Syncthing countinues to report permission denied, that is what the OS tells Syncthing.
Thank you for your reply. My test is just to analyse Mr Syncthing Maintainer’suspect,to prove that the problem is not permission. No offense,but may be there is some bug in syncthing.
I truly know "deletion/creation of a file is not governed by its owner/permissions, but those of the parent directory."So I show you file’s permissions on screenshot,
In one word,It is ok when the file is not many,it will fail when the file become many.
There is literally no difference in how syncthing handles files, regardless if it’s one or many.
I suggest you look at the permissions on the angular files/directories you are having issues with, and not the test case which does not seem to reproduce the problem.
1 Like
Thank you for your reply. I used “test” to show you it was not about permission and the owner of the file. Please look after my first question。It is what I am having issues with.
The syncing percentages of the remote devices are fine: serverB has everything, therefore showing up on serverA as 100%, serverA has nothing, therefore showing up as 0% on serverB.
As for your problem, it isn’t really diagnosable from the information there is. The fact, that it work in a specially crafted test environment is a good start, but does not say prove that it has to work in another environment. From the internals it is highly unlikely, that it has anything to do with one file vs many. If you want to test your hypothesis, ignore everything except for the file you showed in the screenshot and see whether the error still occurs.
As we don’t have widespread reports of such issues, the likely problem is with your setup and the following statement by calmh still holds:
What I could imagine as a cause, though you probably already investigated it: Any dir higher up that has not sufficient permissions (o+x) along the way. Other than that, I would try to get your testing scenario gradually closer to your real scenario, e.g. as a first step set the testing scenario up in /home/wwwroot instead of /home/www.
EDIT: Another thing I forgot: My earlier statement that you should run Syncthing as the user that owns the files still holds: Whenever a file is update from remote it will change ownership to the user that runs Syncthing. You will thus end up in a situation where untouched files are still owned by root:root, the rest by www:www, which is hardly what you want.
thank you very much,Mr simon.I am busy with other things now,I will try your method when I have time.Thanks again.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.