Migrating AFP to SMB

[SwisherSweet]

Hi,

I'm strongly considering using AFP and Mac datasets for my server for the following reasons:

1. Only Mac clients on network.
2. Want to use Spotlight search on shares.
3. Want to use server side copy (SSC).

SMB does not work with 2 and 3. Until there are solutions for this, I think AFP is a better choice for now.

Since AFP is deprecated, I will evenually have to migrate to SMB. Hopefully this will be years away.

Is there a migration path from AFP to SMB? Can I simply change the share type and enable SMB shares?

Also, since AFP supports SSC, will FreeNAS as well since it supports AFP?

 

[Ericloewe]

Can I simply change the share type and enable SMB shares?

Yes, but expect permissions to need to be reworked.

 

[SwisherSweet]

Yes, but expect permissions to need to be reworked.

Thanks. Do you happen to know what that involves?

 

[Ericloewe]

This, pretty much:
https://forums.freenas.org/index.php?resources/freenas-and-samba-smb-permissions-video.8/

 

[anodos]

This, pretty much:
https://forums.freenas.org/index.php?resources/freenas-and-samba-smb-permissions-video.8/

The question is "how does the manner in which Netatalk handles resource forks differ from how Samba handles resource forks"? For an example see discussion here: https://lists.samba.org/archive/samba/2016-April/199422.html

I can't remember if metadata stored in an AFP share is compatible with Samba + vfs_fruit. Some research will have to be done into how to do this safely when the OP migrates. Perhaps the safest way to handle the migration will be:

1. have lots of available free space on the pool
2. create new samba shares
3. mount the AFP share and the SMB shares from an OSX client
4. copy the data from one share to another via client

Unless there's a vfs_fruit parameter that guarantees metadata integrity (I believe one of the primary contributers for fruit was a netatalk dev). I don't use Macs so I can't confidently answer this question.

 

[SwisherSweet]

This, pretty much:
https://forums.freenas.org/index.php?resources/freenas-and-samba-smb-permissions-video.8/

Wow, that's simple. No CLI commands or data conversion process?

Does changing the share/permission type from Mac to Windows cause any data corruption or other problems?

 

[Ericloewe]

The question is "how does the manner in which Netatalk handles resource forks differ from how Samba handles resource forks"? For an example see discussion here: https://lists.samba.org/archive/samba/2016-April/199422.html

I can't remember if metadata stored in an AFP share is compatible with Samba + vfs_fruit. Some research will have to be done into how to do this safely when the OP migrates. Perhaps the safest way to handle the migration will be:

1. have lots of available free space on the pool
2. create new samba shares
3. mount the AFP share and the SMB shares from an OSX client
4. copy the data from one share to another via client

Unless there's a vfs_fruit parameter that guarantees metadata integrity (I believe one of the primary contributers for fruit was a netatalk dev). I don't use Macs so I can't confidently answer this question.

Hmm, that does sound like it could be a problem.

 

[SwisherSweet]

Hmm, that does sound like it could be a problem.

So it's not as simple as it originally seemed?

 

[anodos]

Hmm, that does sound like it could be a problem.

Well, some defaults for fruit are:

• fruit:resource = file use a . AppleDouble file compatible with OS X and netatalk.
• fruit:metadata = netatalk use Netatalk compatible xattr

So in theory it should be serve files from a former AFP share without trashing metadata. It does make me wonder what happens when samba's name mangling algorithm hits files copied with illegal filenames for an SMB share. Ultimately, compatibility will depend on what netatalk defaults to for storing metadata / resource forks.

 

[anodos]

So it's not as simple as it originally seemed?

Isn't that always the case ;)

The safest migration path is what I listed above in #5, but it may be safe if you simply create SMB shares with vfs_fruit enabled.

 

[Ericloewe]

So it's not as simple as it originally seemed?

I don't know and I'm not sure it'll be easy to find someone who can answer this without research...

@anodos's suggestion is the easiest/safest option, but also rather inconvenient. Some research may reveal that Samba can work with what you have, but you'd need to read up on those details, unfortunately.

 

[styno]

There is much more to take into consideration, especially when there are both Windows and Mac clients involved: Filesnames starting with °, space, spaces, ~, ..., filenames that are stupidly long, ... will give troubles when accessed from Windows clients.
As stated earlier: resource forks (although newer macos versions can put them into an alternate stream). Speaking of macos versions and SMB: make sure you do performance tests as older macos versions will only talk SMB1 or SMB2, only the latest versions will speak SMB3.

 

[SwisherSweet]

There is much more to take into consideration, especially when there are both Windows and Mac clients involved: Filesnames starting with °, space, spaces, ~, ..., filenames that are stupidly long, ... will give troubles when accessed from Windows clients.
As stated earlier: resource forks (although newer macos versions can put them into an alternate stream). Speaking of macos versions and SMB: make sure you do performance tests as older macos versions will only talk SMB1 or SMB2, only the latest versions will speak SMB3.

Geez Louise, this is getting exceptionally complicated.

Would I be insulated from having to deal with all this complexity to just do the 4 steps anodos listed when the time comes?

 

[styno]

You shouldn't as you are working in an all-mac environment.

If I was you, I'd test both protocols and see if you can live with Apple's SMB implementation. If not, use AFP and deal with it when apple decides it is time for you to switch.

What we usually do then is take a Mac client that mounts both the old AFP and a new empty SMB share and let that Mac client copy the data and handle all the mac-related filesystem shenanigans.

 

[Stux]

The question is "how does the manner in which Netatalk handles resource forks differ from how Samba handles resource forks"? For an example see discussion here: https://lists.samba.org/archive/samba/2016-April/199422.html

I can't remember if metadata stored in an AFP share is compatible with Samba + vfs_fruit. Some research will have to be done into how to do this safely when the OP migrates. Perhaps the safest way to handle the migration will be:

1. have lots of available free space on the pool
2. create new samba shares
3. mount the AFP share and the SMB shares from an OSX client
4. copy the data from one share to another via client

Unless there's a vfs_fruit parameter that guarantees metadata integrity (I believe one of the primary contributers for fruit was a netatalk dev). I don't use Macs so I can't confidently answer this question.

vfs_fruit, by default, iirc, use netatalk resource format, basically it makes/uses ._<file> files with AppleDouble encoding. Since this is the same as netatalk the resources work fine between AFP and SMB, but the permissions would be different

The only real issue with the ._ format is it's vetoed by default, and the same AppleDouble encoding is used in OS X zip files, so if you extract a zip file on the share, you get an error.