ZFS snapshots are great for rolling backups. Say, we have tank/home mounted at /home. Then a simple zfs snapshot tank/home@TIMESTAMP will give a backup accessible at /home/.zfs/snapshot/TIMESTAMP. However, there is a problem when a user set too lax permissions on some file and corrects this error only after the snapshot has been made. The file will still be readable by the wrong people in the snapshot, and all the user can do is wait until the snapshot is destroyed (which happens via cron job as a part of the rolling backup scheme).

A simple chmod go-rwx /home/.zfs/snapshot/TIMESTAMP/* would help, but snapshots are read-only. I came up with the following solution:

chmod o-rwx /home/.zfs/snapshot
zfs snapshot tank/home@snap-TIMESTAMP
zfs clone tank/home@snap-TIMESTAMP tank/clone-TIMESTAMP
zfs set mountpoint=/root/tmp tank/clone-TIMESTAMP
chmod go-rwx /root/tmp/*
zfs set readonly=on tank/clone-TIMESTAMP
zfs set mountpoint=/backup/TIMESTAMP tank/clone-TIMESTAMP

Now the backup can be accessed in a read-only manner by users at /backup/TIMESTAMP, and it has the modified permissions.

At least one problem with this is that the permissions on /home/.zfs/snapshot will be back to world-readable after a reboot. Can this behavior be changed? We cannot destroy the snapshot, since the clone depends on it.

A much simpler solution is, of course, to store the current permissions of the home directories, then run chmod go-rwx /home/*, take the snapshot, and finally restore the permissions. This brings a number of race conditions, though.

Any better ideas?

Addendum: I have now settled for one dataset per user. So each user has her snapshots in ~/.zfs/snapshot. This is not a 100% solution. If a user has 0701 on her home directory, e.g., to make ~/public_html work, then still an attacker can read a file in a snapshot which had the wrong permissions at the time when the snapshot was taken. However, at least the user can now "pull the plug" in an emergency by making her home directory 0700.

Changing ownership and permissions of each ~/.zfs would be a better solution, but such changes do not survive a reboot. The appropriate chowns and chmods could be run at startup, but this needs to be implemented carefully in order not to create a short period in which files are still exposed.

  • 1
    Have you considered using a separate dataset for each user's home directory? Sep 23, 2019 at 20:05
  • @MichaelHampton Yes, I did, but thought it was crazy. Now thinking again, I feel it is probably the best way to go. It would also have the benefit that users can pick up their backups from ~/.zfs/snapshot and do not have to navigate to /home/.zfs/snapshot. Sep 24, 2019 at 5:58

1 Answer 1


In ZFS, snapshots are immutable: you cannot alter any file properties after the snapshot was taken.

You can try to chmod the snapshot directory (or the .zfs directory) itself. Or, taking another approach, you can set snapdir=hidden

  • I think snapdir=hidden will only hide the directory from ls, but will not forbid access. Sep 24, 2019 at 6:52
  • @LasseKliemann Sure, but depending on your specific needs, maybe it can be sufficient
    – shodanshok
    Sep 24, 2019 at 10:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.