Remove, not replace drives in a pool

There isn’t a more info link.

image

Very strange. What about the output of zpool status at the shell?

To rule something out. The “System Dataset” is not in this pool?

Worst-case scenario, this could be a bug with SCALE (whether or not Apps, VMs, or System Dataset are involved.)

You might have to resort to exporting this pool and then booting into a live Linux ISO (such as the latest Ubuntu) in order to remove the vdev via the command-line.

You’d then re-import the pool into SCALE.

Which version of scale?

image

The system dataset is on the boot pool (as best as I can tell)

Version is Truenas-Scale-23.1.2

Why are you masking stuff? There’s nothing sensitive there, but it tends to get in the way of us helping you.

But with that said, nothing looks out of place. And while you shouldn’t need to do this from the command line, it looks like you may need to. zpool remove tank01 mirror-0 should work. If that runs without error, after a few minutes, post the output of zpool status again.

Sorry if the masking is troublesome. Force of habit.

root@nas[~]# zpool remove tank01 mirror-0
cannot remove mirror-0: permission denied

Haven’t seen that before, but reddit reports that encrypted datasets can cause this. Do you have any?

1 Like

If that’s the reason, and it works, it makes you wonder why it can’t relocate the blocks “raw”.

That was indeed the issue, there was a dataset that was encrypted and locked. Not sure how it got locked, it was volitile storage for some file transfers. I coundn’t find the encryption key but since it wasn’t storing anything crucial, I deleted it.

After that, the first 500gig mirror set deleted successfully (although it initally said it can’t delete because the pool was in use). When I checked back a few days later, the mirror was gone. I am now in the process of deleting the second 500gig mirror set.

Thanks so much everyone for all the help.

This is going to bug me for a long time.

I get uncomfortable when there’s a longstanding limitation that has no technical reason for it.

Why would the dataset(s) need to be unlocked to continue with this action? To get around “permission denied”?

We can send and receive locked encrypted datasets. Obviously ZFS is capable of handling the blocks-on-disk without the need to load the decryption key.