ZFS
ReviewAudited by ClawScan on May 1, 2026.
Overview
This is a coherent ZFS administration skill with powerful but expected storage-management examples that should be used carefully.
Install/use this only if you intend the agent to help with real ZFS administration. Before running any suggested command, verify disk IDs, pool names, dataset names, and backup status; be especially careful with rollback, destroy, recv -F, zpool add, cron automation, passphrase-less SSH keys, and NFS no_root_squash examples.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A mistaken command could change pool topology, roll back files, or delete snapshots/data.
These are direct ZFS storage mutation commands. They are central to the skill's purpose and partly cautioned, but incorrect device or dataset targets can cause data loss or hard-to-reverse pool changes.
# Add vdev (cannot be undone — plan carefully) zpool add tank mirror /dev/disk/by-id/new1 /dev/disk/by-id/new2 ... zfs rollback tank/data@daily_2024-01-15 ... zfs destroy tank/data@old-snapshot
Treat ZFS commands as privileged admin actions: verify devices and datasets, prefer dry-run/status checks where available, and require explicit confirmation before destructive operations.
If the key or primary host is compromised, an attacker could receive, roll back, or destroy backup datasets within the delegated scope.
The replication guide shows a passphrase-less automation key and delegated ZFS permissions that can modify replica datasets. This is expected for automated replication, but it is sensitive authority.
SSH key-based auth (no passphrase for automation): ... ssh-keygen -t ed25519 -f /root/.ssh/zfsrepl_key -N "" ... zfs allow -u zfsrepl create,mount,receive,destroy,rollback,hold,release backup
Use least-privilege ZFS permissions, strong file permissions, SSH authorized_keys restrictions such as from= and no-agent-forwarding, and monitoring for replication activity.
On an untrusted or broad network, clients could gain excessive write/control access to shared files.
The NFS sharing example uses no_root_squash, which lets root on matching client systems act with root-like privileges on the exported share. It is an optional example, but privilege-sensitive.
zfs set sharenfs="rw=@10.0.0.0/24,no_root_squash" tank/shared
Avoid no_root_squash unless explicitly required and trusted; scope exports to specific hosts or subnets and use safer NFS permissions by default.
Misconfigured scheduled jobs could repeatedly replicate mistakes, consume resources, or prune snapshots according to the configured policy.
The guide includes cron jobs that keep running after setup. They are disclosed backup/snapshot automation examples, not hidden persistence, but recurring jobs can continue affecting storage.
0 * * * * /usr/sbin/syncoid -r tank remote:backup/tank --no-sync-snap 2>&1 | logger -t syncoid ... */15 * * * * /usr/sbin/sanoid --cron
Test automation manually first, review retention settings, monitor logs, and document how to disable or pause the cron jobs.
Users may need to independently verify provenance and ensure the ZFS tools are installed before following the instructions or running the helper script.
The skill includes a shell helper and ZFS CLI guidance, but registry metadata provides no source/homepage and no declared zfs/zpool binary requirements. The included files are visible, so this is a minor provenance/dependency notice rather than suspicious behavior.
Source: unknown; Homepage: none ... Required binaries (all must exist): none
Review the bundled script before use, install ZFS tools from trusted OS packages, and verify commands against OpenZFS documentation for the target platform.