# How to set certain nodes as \[read only, backup, slave\]?
**URL:** https://forum.syncthing.net/t/how-to-set-certain-nodes-as-read-only-backup-slave/899
**Category:** Support
**Created:** [September 9, 2014, 2:52am UTC](https://forum.syncthing.net/t/how-to-set-certain-nodes-as-read-only-backup-slave/899 "2014-09-09T02:52:56Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@jasonfish](https://forum.syncthing.net/u/jasonfish)
#### Post date: [September 9, 2014, 2:52am UTC](https://forum.syncthing.net/t/how-to-set-certain-nodes-as-read-only-backup-slave/899/1 "2014-09-09T02:52:57Z")
I have a couple machines which are accessed by other individuals. While I do want all machines to receive all changes, I do NOT want any changes made on these specific machines to filter back to the rest of the nodes. A “backup TO here” scenario. How can I do this?
---
### Author:  [@calmh](https://forum.syncthing.net/u/calmh)
#### Post date: [September 9, 2014, 2:39pm UTC](https://forum.syncthing.net/t/how-to-set-certain-nodes-as-read-only-backup-slave/899/2 "2014-09-09T14:39:39Z")
Currently, you can’t. It’s [issue 62](https://github.com/syncthing/syncthing/issues/62), although it’s a bit vaguely worded.
---
### Author:  [@NickPyz](https://forum.syncthing.net/u/NickPyz)
#### Post date: [September 9, 2014, 2:47pm UTC](https://forum.syncthing.net/t/how-to-set-certain-nodes-as-read-only-backup-slave/899/3 "2014-09-09T14:47:05Z")
This use case is not presently handled by Syncthing. Look thru the forums, this topic has been discussed before.
In a 2 device cluster, you can set up device A as “Master”, and changes made on device B will not come back to A. This setting is repo specific, in the repository edit screen.
However, in a more complicated cluster like you described, you would require more than 1 “Master” - and Master repos will not update each other.
---
### Author:  [@rdiaz02](https://forum.syncthing.net/u/rdiaz02)
#### Post date: [February 24, 2015, 8:48pm UTC](https://forum.syncthing.net/t/how-to-set-certain-nodes-as-read-only-backup-slave/899/4 "2015-02-24T20:48:16Z")
But I think you actually can if you link the two masters (with none as a master) and then add another “folder pair” with one of the masters and the slave. See more here: [Three node syncthing with two masters](https://forum.syncthing.net/t/three-node-syncthing-with-two-masters/415/4):
> [@Three node syncthing with two masters](https://forum.syncthing.net/t/three-node-syncthing-with-two-masters/415/4):
>
> But I think there is a relatively simple solution. Suppose you want changes to be synced two-way between A and B, but you want C to accept all changes and not propagate any (so A and B would both be masters, and C would be what other software calls read-only nodes).
>
> Suppose the things you want synced live in directory ~/D1 (at least in machine A).
>
> In A add two folders (I mean, “Folders” in the sense of the user interface of ST, not in the “directory of a filesystem” sense)
>
> - A-one-way-C
> - A-two-way-B
>
> both of them use as Folder Path ~/D1, but in A-one-way-C, “Folder master” is checked.
>
> Now, in both B and C accept the creation of the new folder, use ~/D1 (or whatever) in your filesystem, and you are done.
>
> I just tried it, and it works fine. The key idea is that syncthing has no trouble using the same directory in different “Folders”, so you can share it in different ways (as “Master” and as non master).
>
> This is not as simple as checking boxes for “read only”, etc, but it seems to work and is just fine (at least for small numbers of interconnected nodes).
>
> P.S. You might also think about adding, in B, a B-one-way-C but this to me is confusing and when playing with it, it can lead to trouble. This makes sense: if you have just
>
> A-one-way-C A-two-way-B
>
> it is unambiguous how changes can and cannot propagate. If you add B-one-way-C then it ain’t.
---
### Author:  [@system](https://forum.syncthing.net/u/system)
#### Post date: [May 12, 2017, 12:56pm UTC](https://forum.syncthing.net/t/how-to-set-certain-nodes-as-read-only-backup-slave/899/5 "2017-05-12T12:56:51Z")