Hey All
I’m trying to pull snapshots from a TrueNAS Scale box to an Alma Linux 9 box with a simple script I wrote that calls syncoid. I’ve used the script before for TrueNAS Core and Alma 8 with no issues.
Sanoid/syncoid have been installed on the NAS.
This time around I seem to have three issues. Tackling the first one first,
syncoid is warning that resume isn’t available? Any ideas how that’s possible? zfs recv -s does show ‘s’ as an option?
»»»» /usr/local/bin/syncoid-Pull_From_Scale
Start time: Tue Oct 22 10:20:09 EDT 2024
DEBUG: SSHCMD: ssh
DEBUG: checking availability of lz4 on source...
DEBUG: checking availability of lz4 on target...
DEBUG: checking availability of lz4 on local machine...
DEBUG: checking availability of mbuffer on source...
DEBUG: checking availability of mbuffer on target...
DEBUG: checking availability of pv on local machine...
DEBUG: checking availability of zfs resume feature on source...
DEBUG: checking availability of zfs resume feature on target...
WARN: ZFS resume feature not available on source machine - sync will continue without resume support.
DEBUG: recursive sync of /mnt/tank/dataset
DEBUG: getting list of child datasets on /mnt/tank/dataset using ssh -S /tmp/syncoid-admin@nas.example.com-1729606809-6757 admin@nas.example.com sudo zfs list -o name,origin -t filesystem,volume -Hr ''"'"'/mnt/tank/dataset'"'"'' |...
sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
sudo: a password is required
CRITICAL ERROR: no datasets found at /usr/local/sbin/syncoid line 202.
End time: Tue Oct 22 10:20:10 EDT 2024
Just talking to myself at this point 
I have cleared the other issues by allowing zfs and syncoid on the NAS to run with sudo without a password, and fixing up a PATH issue.
I still have that no resume error, which doesn’t make a lot of sense to me - it’s Debian, right? and Debian zfs must have resume?
Check the version of zfs at each end - assuming they are recent enough, the culprit could be that you’ve not yet upgraded the pool to be fully compatible with the latest version. I don’t have any other quick hunches at this point. Specifically you need the feature@extensible_dataset for resume support and a quick zpool get feature@extensible_dataset on both the receiving and sending sides should let you know where the issue is.
1 Like
Thanks for the pointer to the feature flag. It is on, on both ends.
I noted however that under the one account zpool is not available as is, it needs to be /sbin/zpool
I wonder if $path issues are causing syncoid to misread the situation.
Possibly. Also, check to make certain that the utilities and libraries are in sync on both ends–apparently-false reports that resume aren’t available can be a symptom of that kind of mismatch (eg if your kernel updates, and the kernel modules along with it, but your userland commands and libraries do not).
Hmmm - was doing something else on two different systems today and got that same erroneous warning.
»»»» sudo /usr/local/sbin/syncoid -r 'nas:/tank/backup' 'tank/backup'
root@nas password:
WARN: ZFS resume feature not available on source machine - sync will continue without resume support.
ERROR: cannot open '/tank/backuptank/backup': No such file or directory
# snipped more no such file errors
»»»» sudo /usr/local/sbin/syncoid -r 'nas46b:tank/backup' 'tank/backup'
root@nas password:
INFO: Sending oldest full snapshot tank/backup@syncoid_nas01C.muskokaauto.com_2024-07-05:04:29:09-GMT-04:00 (~ 2.8 GB) to new target filesystem:
# etc etc
The first attempt I’d put a leading / on the source dataset name. So the no such file errors make sense. But it also warned about no resume!
I guess if there’s no source dataset found, it assumes the resume flag isn’t set on this mythical source dataset? Isn’t that a bug? or am I looking at it wrong?
You’re correct; it’s basically falling through to that error condition rather than stopping at that error on the send side. That is definitely a bug, it’s just not one that anybody has put the time in to fix yet.