Created a pool, and checked zpool history immediately after. Found this:
History for ‘Bench_pool’:
2026-02-24.22:17:40 py-libzfs: zpool create (options) … Bench_pool (disks)
2026-02-24.22:17:40 py-libzfs: zfs inherit Bench_pool
The funny thing is, that last one isnt a valid zfs command - it needs further args, gets rejected if retyped in console. So what’s it doing in zpool history?
Probably triggered by something in the TrueNAS middleware code.
There might be logic that passes an array of properties to be “reset” (inherited) when certain actions are done in the GUI. It’s likely that there are cases where nothing is passed, and so you end up with a nonsensical invalid command.
EDIT: I was right. Try this now. Go to a dataset’s properties. Don’t change anything. Click the “Save” button. Now check with zpool history and you’ll see pointless inherits that don’t do anything.
EDIT 2: Isn’t it narcissistic to admit to yourself you were right about something when no one really asked?
EDIT 3: Talking to yourself is another red flag.
One has got to talk to an intelligent person every once in a while.
As much as anything surprised that an invalid command that didn’t get executed because it can’t be executed, is able to be added to pool history regardless. Just a bit surprised!
lilbzfs has an api to insert arbitrary strings into non-internal zpool history. It is not meant to be a replay log though so having commands in it that can’t be copy-pasted out is not a problem. We use py-libzfs prefix to indicate that the change was made via python library as opposed to zfs tools.
In 25.10 and later, logic is here:
It should be in format <prefix>: zfs inherit <property name> <dataset name>
