Moving an EDA500 Expansion Chassis to a New NAS

---

StephenB wrote:

---

Sandshark wrote:

The only thing missing from the process I went through is how to add the share to the GUI so that permissions can be set.  If somebody can share the secret to that, the process I went through above should work.

---

Did you try creating a share with a different name?  Then delete the subvolume from ssh, and rename the original subvolume to match the share name.

---

I misspoke a bit.  There is a need to get the whole volume recognized by the GUI, not just a share.  I find it odd that I can create a new volume "behind the scenes" with SSH and mount it such that the GUI recognizes it, but I cannot mount an assembled one.  Everything works as desired from SSH, so data can be recovered to another volume, but the volume cannot be made visible to the GUI so you can just move on using it like any other volume. 

This works:

     mdadm --create the RAID array

    mkfs.btrfs the volume 

    mkdir the mount point

    mount to the mountpoint

     then add the mount to /etc/fstab

The volume is visible to the GUI, including surviving a reboot.

But if you substitute mdadm --assemble --scan for creation and skip making the file system (since it's already there), the GUI doesn't see the volume, even though it's completely accessible via SSH.  I don't think it survived a reboot (RAID had to be reassembled again), but I'm foggy on that since it didn't really matter without GUI recognition.

I have found some information saying that an mdadm RAID can be re-created using the same parameters as when it was orignally created, normally reserved for when re-assembly doesn't work.  I've not tried that, as it is clearly documented as a last-ditch effort to recover an otherwise unrecoverable array.