Load config from v8.0 not working with new v11.2 install

[verbage]

Can anybody comment on trying to load a configuration/settings database from a FreeNAS-8.0-RELEASE-i386 install (2011 time frame) into a fresh new FreeNAS-11.2-RELEASE-U1 install? I am trying to do that now, but it does not seem to working. After doing the configuration/settings import with the new system, as I watch the system reboot on the console, I see a lot errors that seem to crop up on the database conversion import, but it does at least finish. Then, when I try to log into the web UI of the new system (with old settings that are now theoretically imported), the login seems to hang. I can refresh the webpage, and eventually get into the web UI, but then none of the settings that I tried to import seem to have been taken.

So, is there too much of a difference between a v8.0 system and new v11.2 install to make a settings export/import operation possible?

I do not have a terribly complex configuration so recreating it by hand would not be too much of an issue. But more than anything, I have two 2TB drives that were in a ZFS mirror config under the old v8.0 system, and I'd like them to arrive intact as a mirror into this new v11.2 system, but that has not happened. If I could simply manually recreate the ZFS mirror with those the two drives under the new v11.2 install--while maintaining all the data that they contain--that would be fine, too.

Thanks for any comments or guidance you might be able to offer!

 

[verbage]

Well, that was simple enough--the new v11.2 install was able to see the old ZFS mirror pool so I was able to simply import it. I will just redo the rest of the settings manually.

I suspect that v8.0 is just too old for the settings export-->import operation to work, but if anybody know this for certain, it would be nice to confirm it. The online documentation does not seem to say this can't be done so that's why I gave it a try.

On another note, just a warm thank you to the FreeNAS developers because the v8.0 system has been chugging along for the last 8 years with nary a hiccup. I was finally hitting capacity so I quadrupled storage capacity and doubled RAM, but otherwise, I have reused everything else, and I expect another long stretch of worry-free service.

 

[verbage]

Just a note to potentially help future folks like me doing an 8.0-->11.2 upgrade, and this concerns rsync and setting up ZFS pools as a Windows Share Type. In particular, this option for a Windows Share Type did not exist back in FreeNAS 8.0 (at least I don't remember it!). But I did encounter it as I was setting up both my old and new ZFS mirror pools on this new 11.2 install. The help message for the Share Type option simply says "Set the type of client that will most often use this dataset," and gives Unix, Windows, and Mac as options. Since I use the system primarily as a data store for various Windows machines around the house, I chose the Windows option, and did not think much of it.

Anyway, I planned to use rsync to clone the data from the old mirror to the new mirror so I fired up the process with a simple:

rsync -ahP /mnt/OldMirror/ /mnt/NewMirror

I saw the drives start going crazy with activity, and files streaming along the console so everything looked great. But when I returned after about an hour, the crazy drive activity had stopped, and on the console, I saw that rsync seemed to be hung. Hmmm, this was not terribly worrying as rsync has hung on me in the past. So I simply broke out, restarted the same command to continue, and it seemed to pick up where it left off. But after another hour, I was back to the same hung rsync situation. This time when I broke out of the process, I paid more attention to the errors I saw, which were along the lines of:

rsync: mkstemp "/mnt/NewMirror/MyFile.fwOXsx" failed: Operation not permitted (1)

I started doing some digging, and found quite a few comments about seemingly close issues, and finally ended up at https://redmine.ixsystems.com/issues/12127. In particular, it was the comment by James McDonald that made it all click--he wrote, "I was seeing these same messages while using rsync manually... Turns out that dataset was configured with Windows as the Share Type in the dataset/volume configuration. As soon as I changed it to Unix and tried again, the rsync proceeded with no errors." Fortunately, the solution was provided by none other than Josh Paetzel, "You need to add the --no-perms option to your rsync command... However you'll want to ensure you are using -A so that the ACLs are transfered over."

So I modified my command to:

rsync -ahP -A --no-perms /mnt/OldMirror/ /mnt/NewMirror

And now after running all night, there are only a few hundred GBs of data to go, woo-hoo!