Replication dataset user rights cannot be modified (my own fault, usability thing)

TrueNAS General
1

Hello,

I struggled for a while to find out why I couldn’t modify my replicated dataset’s rights. Answer was that I didn’t pay attention to Destination Dataset Read-only Policy* setting when creating a replication task and thus I couldn’t change rights on destination dataset after replication. Is there some reason why this setting is “read only” by default in replication task?

2

I would imagine since the replication is often used for backups it’s in order to avoid changes on the destination that are not reflected by the source Snapshots.

You can set it to ignore to avoid a RO replication.

Use zfs set readonly=off on the destination if needed.[1] I assume you should in addition set the RO policy to ignore it you continue this replication task on a regular basis.

  1. https://openzfs.github.io/openzfs-docs/man/master/8/zfs-set.8.html ↩︎

2 Likes
3

Note that editing permissions is still a change to the dataset, and thus will impede further replication unless you roll back to the latest common snapshot between send and recv sides.

4 Likes
4

Hi ericloewe,

Can you perhaps explain that in a bit more detail?

Will changing a dataset (either permissions or actually changing the data) that is a target for replication

  1. prevent the replication from being run?
    a) until the changes are reverted back manually?
    b) or until the changes are reverted back by rolling back to an unchanged snapshot?
  2. not prevent the replication to be run, but will silently “corrupt” newly replicated snapshots?
    a) impacting only the files or things that have been changed?
    b) impacting potentially more than just the files or things that have been changed?
  3. or will the replication of new snapshots still properly work, but be “impeded” in another way (please clarify)?

Thanks!

5

This.

1 Like
6

Thanks for the response!!

However, I just did a quick test and it does seem a bit different on TrueNAS Scale?

Here are my findings:

  • I disable the zfs readonly flag on the target dataset and configure the replication task to ignore the readonly flag
  • I copy a folder with files to my target dataset
  • I run the replication. It doesn’t fail and it actually removes the folder/files that I manually added

So could it be that TrueNAS detects that manual modifications were made on the target dataset and that it automatically rolls back to the latest snapshot before starting the replication?
Or is there still risk that I introduce data corruption by manually modifying the target dataset somehow?

7

No, that’s TrueNAS automatically forcing the rollback.

1 Like
8

And thus you silently lose data.

By marking the replicated dataset read only, you don’t accidentally store data somewhere where it will get automatically erased.

2 Likes
9

Ah ok,

So that’s actually good in my opinion… Then you have predictable behaviour that does not cause any corruption or damage to the dataset.

Thanks for the clarification!