Upgraded: .mac vs .apple, upgrade versions with encrypted main pool

[G Brown]

Hello,

I am finally upgrading from version 9.2.X to version 9.3.X, and I have a question or two.


First kudos to all the hard workers. There is lots of progress here!


My question is about these types of data sets called UNIX, Mac, or Windows, and the permissions associated with these. The old version had a .apple type whereas the new version has a .mac set into the data set root. As I restored my data from backup snapshots I have the .apple set into the root of the data sets.

Q1:
For AppleShare what does this new fangled .Mac thing do? It seems to work fine with UNIX type set up. In my missing anything? Should I set .mac into the data set roots? Will that make Apple ACLs work properly? This is new stuff and migrating from the old stuff didn't seem covered in the documentation. There doesn't seem to be a lot of difference between UNIX and Mac.


Q2:
I might as well ask as well, in migrating from the old to the new version the documentation might mention if your pool is encrypted, then you want to store your config into RAM – not the main encrypted pool. With 2020 hindsight I see that there is no way it could reboot and continue the version upgrade as the pool in which some stored important information was encrypted so I had to do a complete new install, then restore the saved config data. Is that correct? Thanks.

 

[m0nkey_]

A1, when creating a new dataset, set it to 'Apple' if you're exporting it over AFP. As far as I know, it does something funky with ZFS (well, in the case of Apple, it's probably still UNIX file permissions) to let it know it's to be handled like a Apple filesystem.

A2, as with any encrypted pool, backup your configuration, encryption and recovery keys. That last one, incredibly important. You don't have that when things crash and burn, you suddenly become a 'unauthorized user' and are locked out. Wave bye-bye to your data.

Just a point on encryption. It is such a pain the the ass when used with FreeNAS. At most it prevents access to the data if the drives are physically stolen, it will not prevent data from being accessed if it's in a running system. You're better off using a TrueCrypt (aka VeraCrypt) virtual disk to keep your secret documents a secret.

If your data is really important, I wouldn't put it on an encrypted pool. Drive replacements are far more involved with encrypted pools. Make sure you have backups.

 

[G Brown]

A1:
Currently there isn't much documentation concerning this. It seems that the .mac has to do with setting ACL's, and the .apple has to do with AppleShare.

Here's a post where somebody else's trying to get to the bottom of this:

https://forums.freenas.org/index.php?threads/dataset-share-type-purpose.34809/#post-208632

For ACL's to work all the systems must be in a common security directory.

A2:
I will put in a ticket so perhaps the documentation will contain a note to use RAM to store the upgrade info, so when the system reboots it can access it via the RAM.

@monkey:
I don't think you become an unauthorized user, but without the key your data partition is locked up. I have been using encryption and have not found it burdensome. When you reboot you do have to unlock your data, yes. Drive replacements are discussed in the manual, and yes it is good to rekey all the drives. And yes you should always have backups: theft, fire, earthquakes, tornadoes, hurricanes, etc. Backups should be off-site, so if the place burns down you still have a copy of your data. I will make a post about the backup scripts I use; they can be found here:
https://github.com/gitgb/freenasscripts