SOLVED Replication Failed - Broken Pipe - internal pool to pool - copied files don't show

[Kris Heslop]

Background: I am attempting to expand my HDD pool for media and files to be larger, plus hopefully get Plex to have faster response when browsing on the LAN plus move to some SSD pools for iocage, VMs, and some minor data files.

Instead the replications fail, saying Broken Pipe. The Disks show TBs of data but nothing populates when I attempt to view on Windows or Mac.

To do this transition my first step was to backup my:
(Plex) media pool (plus some others) from
(WD White 7-10TBz2)

to a temp pool
(WD White 3-12 Stripe)

so I can upgrade to
9-10 TBz2,

Plus move a single disk (WD Red 4TB-using under 1-TB) pool to multiple SSD pools for iocage, system data VMs and some data.

I was going to add an SSD for meta data, but since that can cause data loss, I am holding off on that.

Accessing SSH with tmux via Terminal on a Mac, I created snapshots and then attempted to replicate on the new or interim pools. These all seem to have failed with messages about failed...broken pipes. I have attempted to redo these, but it does not appear to surrender the prior space, so I have deleted and started over again, or tried to break into pieces.

The new pools/replications show that space is being used, but nothing populates when attempting to view.

I have searched both these forums and Reddit, and general google, but nothing seems to provide clarity of how to get this to actually complete, and what might be going on. (BTW I use Mac, but have resurrected a Win10 machine that I use for transferring media to the server.)

I have been using FreeNAS/TrueNAS since 2016, although often struggle to understand what the flags/codes mean when doing cli so if it doesn't work, I search but often it is pretty cryptic.

 

[Kris Heslop]

I googled this and found that this process actually is actually streamlined in the Tasks: Replications.

Since I had not figured out why nothing was showing, and the replication aborted midstream, I deleted the pool and started over, this time using the GUI replication tool for a local copy/replication. TrueNas Documentation - Local Replication, and location under "Tasks:Replications"

After the Replication was completed the files and subdirectories still would didn't show up in my computer's directory listings.

Then googling further I found some threads on the replicated pool being set to readonly=true causing it to either not mount or not show in the directories and that sometimes replications change this setting.

Still don't know why the constant broken pipe, but the automated replication eliminated that issue.

As I mentioned, some threads said that this "readonly" setting prevented them from being able to mount the pool, in my case the pool was mounted but showed "Nothing" in the list of directories...

To check I used the Command-Line in the shell with: zfs get all [pool_name]

This listed the ZFS parameters for the pool, and under "readonly" it equaled "true"

I guess I could have also looked in the Pools listing page, but the thread I was using (unable to go back to though) showed the "get" results, which are more detailed. The pool's summary screen likely said "inherits" (like it does now) even though it did not inherit the prior pool's readonly=false.

Using: zfs set readonly=false [pool_name]

No leading "/" was required, such that the syntax for a pool called "Trans" would be: zfs set readonly=false Trans

Since my pool was mounted, immediately after making the change when I looked in my computer's file manager, all the subdirectories and files were listed.
Not sure why or how to prevent this flag from flipping from false to true next time, but now I know what to do.

Resources:
Support: Replicated datasets does not show in dir listing.
Oracle.com: Managing ZFS properties
Oracle doc: Introducing ZFS Properties