or Connect
AppleInsider › Forums › Software › Mac OS X › Apple shifts from AFP file sharing to SMB2 in OS X 10.9 Mavericks
New Posts  All Forums:Forum Nav:

Apple shifts from AFP file sharing to SMB2 in OS X 10.9 Mavericks

post #1 of 43
Thread Starter 
In OS X Mavericks, Apple will begin migrating from its own legacy Apple Filing Protocol to Microsoft's SMB2 in an effort to enhance performance, security and cross platform file sharing.

OS X Mavericks


Macs running OS X 10.9 Mavericks will automatically default to using SMB2 when talking to each other, and fall back to AFP when file sharing with Macs running previous versions of OS X or when working with Time Machine backups.

From AFP to SMB2



Apple has maintained and enhanced its own AFP file sharing since it was first introduced in the late 1980s as part of the original Macintosh's easy-to-use AppleTalk networking system (below). The company then transitioned AFP from its own proprietary AppleTalk transport to the Internet's TCP/IP, where it has remained the default protocol for Mac to Mac "personal file sharing" on OS X.

Leopard Parental Controls


SMB ("Server Message Block") originated at IBM, but was popularized and greatly expanded by Microsoft as the default Windows File Sharing protocol. Like Apple, Microsoft transitioned its SMB file sharing protocol from its original NetBIOS transport to TCP/IP.

In the late 90s, Microsoft attempted to rename SMB as CIFS (the "Common Internet File System") in an effort to make it sound more like a cross platform standard, although the new name and the use of SMB as the Internet's file sharing protocol never really took off.

While proprietary to Microsoft, the SMB protocol was reverse engineered to create the Samba open source project to allow Unix-like operating systems to share files with Windows PCs. Apple incorporated Samba into OS X 10.2 to support file and network directory services with Windows PCs, resulting in the simple option to enable Windows File Sharing on Macs.

With the release of Windows Vista, Microsoft greatly revamped SMB to clear out old legacy complications and enhance its performance, capabilities and security. This resulted in SMB2. Microsoft further enhanced its SMB2 protocol with version 2.1 in Windows 7 and a 2.2 version for Windows 8 that is also referred to as SMB 3.0. Apple doesn't distinguish between these variants in its own documentation.

From Samba to SMBX



Samba didn't initially support Microsoft's new SMB2; additionally, the project decided to move its future development (including support for SMB2) to the more strict GPLv3 license. That prevented Apple from realistically using the software commercially.

For OS X 10.7 Lion, Apple wrote its own software for Windows File Sharing under the name "SMBX" to replace Samba, adding initial support for Microsoft's SMB2 at the same time.

Rather than maintaining both AFP and SMBX in parallel, Apple is now consolidating its future efforts in its own implementation of Microsoft's SMB2 protocol. Macs running OS X 10.9 Mavericks will use SMB2 as their default file sharing protocol when connecting to each other or to PCs running Windows Vista, 7 or 8.

In a public technology overview, Apple says, "SMB2 is superfast, increases security, and improves Windows compatibility."SMB2 is superfast, increases security, and improves Windows compatibility.

The company also outlines that "SMB2 features Resource Compounding, allowing multiple requests to be sent in a single request. In addition, SMB2 can use large reads and writes to make better use of faster networks as well as large MTU support for blazing speeds on 10 Gigabit Ethernet. It aggressively caches file and folder properties and uses opportunistic locking to enable better caching of data. It?s even more reliable, thanks to the ability to transparently reconnect to servers in the event of a temporary disconnect."

Apple will continue to support AFP for file sharing with Macs running previous versions of OS X and with Time Machine backup systems. OS X Mavericks also includes support for NFS v3 and v4, which are commonly used on Linux and Oracle's Solaris for automounting file shares.

Support for Windows ACLs; NTFS remains read only



Apple's development of OS X has similarly incorporated other technologies from Microsoft's Windows, including support for Windows-style ACLs (Access Control Lists), a more robust and fine-grained system for implementing file-based permissions that offered a variety of improvements over the existing BSD Unix-style permissions used in prior versions of OS X.

Support for ACLs, introduced in OS X 10.4 Tiger in 2004, helped enhance connectivity between Macs and PCs and Windows Active Directory services.

In terms of file systems, OS X Mavericks continues to use HFS+, with support for file system journaling. OS X continues to support Microsoft's basic FAT32 file system and includes read-only support for Windows' default NTFS.
post #2 of 43
This make me kinda nostalgic. I still remember AppleShare server for System 7.
post #3 of 43
Queue open source zealots criticising this move, oblivious to the problems for a commercial entity that tried to comply with GPLv3 .

PS:
Quote:
In a public technology overview, Apple says, "SMB2 is superfast, increases security, and improves Windows compatibility."SMB2 is superfast, increases security, and improves Windows compatibility.

does saying it twice make it more truthy? 1smile.gif
It's the heat death of the universe, my friends.
Reply
It's the heat death of the universe, my friends.
Reply
post #4 of 43
Will .dotfiles disappear now on Linux samba servers?
post #5 of 43
This is good, IMO. So much easier to plug a Mac into a Windows network.
post #6 of 43
Seems convoluted. How long till they switch time machine to smb2 anddeprecate AFP completely?
post #7 of 43
Why not switch Time Machine to SMB2, too?
post #8 of 43
Quote:
Originally Posted by CustomTB View Post

Seems convoluted. How long till they switch time machine to smb2 anddeprecate AFP completely?

 

probably finite resources 

post #9 of 43
Quote:
Originally Posted by Don108 View Post

Why not switch Time Machine to SMB2, too?

Cause TM is a hack that's way too dependent on the network protocol and file system used; both in terms of source and target, it's a pity Apple ditched the ZFS strategy, it would have predestined for use with TM in a much more elegant and efficient way.
post #10 of 43
Quote:
Originally Posted by aaarrrgggh View Post

Will .dotfiles disappear now on Linux samba servers?

Doubt it. Windows system will read dot files as visible regardless of how they got there if you have show extensions enabled. Until OS X quits creating dot files there will likely be this issue, but they should not show up on Linux

Life is too short to drink bad coffee.

Reply

Life is too short to drink bad coffee.

Reply
post #11 of 43
Quote:
Originally Posted by CustomTB View Post

Seems convoluted.
Not really, all this is really doing is providing Apple with a compatibility feature they need. It might not be well handled as far as promotion goes nut it probably isn't a high priority.
Quote:
How long till they switch time machine to smb2 anddeprecate AFP completely?
I would imagine there would be a Time Machine replacement sometime in the future. That is only if this is a long term solution. Their goal may be compatibility first and then graduation to something more advanced. Sometimes it is hard to tell with Apple.
post #12 of 43
Quote:
Originally Posted by aaarrrgggh View Post

Will .dotfiles disappear now on Linux samba servers?

 

 

Not likely. Until then, Blue Harvest. http://www.zeroonetwenty.com/blueharvest/

post #13 of 43
I know Aperture libraries require Apple's file system attributes - how can that be supported in SMB, or is it?

D
post #14 of 43
Quote:
Originally Posted by wizard69 View Post


Not really, all this is really doing is providing Apple with a compatibility feature they need. It might not be well handled as far as promotion goes nut it probably isn't a high priority.
I would imagine there would be a Time Machine replacement sometime in the future. That is only if this is a long term solution. Their goal may be compatibility first and then graduation to something more advanced. Sometimes it is hard to tell with Apple.

 

They could easily keep both protocols around.  They have always supported Samba, it was just that their quirky non-standard implementation of it caused huge problems.  

post #15 of 43
Quote:
Originally Posted by Entropys View Post

Queue open source zealots criticising this move, oblivious to the problems for a commercial entity that tried to comply with GPLv3 .

PS:
does saying it twice make it more truthy? 1smile.gif

 

Twice is encouraging, it takes three times for truth:

 

"Just the place for a Snark!" the Bellman cried,
As he landed his crew with care;
Supporting each man on the top of the tide
By a finger entwined in his hair.

"Just the place for a Snark! I have said it twice:
That alone should encourage the crew.
Just the place for a Snark! I have said it thrice:
What I tell you three times is true."

                                                              1smile.gif

 
"That (the) world is moving so quickly that iOS is already amongst the older mobile operating systems in active development today." — The Verge
Reply
"That (the) world is moving so quickly that iOS is already amongst the older mobile operating systems in active development today." — The Verge
Reply
post #16 of 43

"Apple will begin migrating from its own legacy Apple Filing Protocol to Microsoft's SMB2 in an effort to enhance performance, security and cross platform file sharing."

 

Never thought I would see a statement from Apple that had: Microsoft,  enhance performance and security, all in the same sentence!

post #17 of 43
NTFS support for read and write is also needed!
post #18 of 43
The move away from open source is a pity. I understand the complexities and vagaries of GPLv3. But I would have much preferred to see Samba maintained on OS X.

At least they are keeping NFS.

It's a pity ZFS never survived. It was potentially one of those great technologies.

SMB2 seems to be more about 'compatibility' than about superior functionality. Apple has given up on the desktop. I can understand why in one sense, since so much more is made from iOS devices, the App Stores, iTunes etc. But the desktop market is nothing to sneeze at.

OS X is slowly morphing away from good ol Unix into some kind of budget OS. Real innovation seems to be dying. The art of good UI seems to be dying. And that synergy that Apple had for so long between form and function appears to be lost.
post #19 of 43

Can anyone tell me how the screen saver works with multiple displays?

 

Seems they finally fixed everything with displays that was missing in Mountain Lion.  I'm very excited they fixed everything I sent in.

 

I'm curious if you can use a screen saver on an inactive display (if you have three or four), while still working another display.

 

Also, can someone please check to see if Airplaying to an Apple TV downgrades your current displays to 1080P as it does in Mountain Lion?

 

I'm at the conference, so I can't check.  Only one display here.

 

Someone please let me know!

 

I was focused on in the keynote THREE TIMES!  LOL!

 

Edit:  Looks like I'll get to ask tomorrow (or today, still stuck on eastern time).  Someone here must know already.


Edited by Vadania - 6/12/13 at 1:34am
post #20 of 43

Hmm...i like how AFP worked and how secure it was. Also connecting to remote Macs was a breeze with cmd+K In Finder and going the AFP route. Now i assume if i want to connect to a remote Mac (using Mavericks) i have to forward the SMB ports 139 and 445 for it to work, which in many cases may create a problem since many ISPs block those ports due to security issues. 1bugeye.gif

post #21 of 43
Don't forget that windows creates Hidden files on removable media as well, just that they are hidden so we only see those created by Macs. I have a HD with over 2GB used by a hidden "System Volume Information" which I do not have permission to remove.
post #22 of 43

I think it's safe to anticipate this could cause a lot of growing pains, lots of reason to wait some months after release for the first "paying beta testers" to see how it pans out and gets patched.

post #23 of 43
For those asking, Time Machine can't be done over SMB - there is no decent Windows equivalent of a symbolic link or hard link and certainly no method of producing one over the SMB protocol.

It's a Unix invention that allows many file pointers to point to the same file making it appear as if a file exists in many locations, whereas it only exists once with many links to it.

That's how Time Machine is so conservative with disk space.

Also dot files and displaying them over SMB is optional and configured on the SMB server, problem is if you don't show them they can't be edited. So hiding them silently would require a modification of the SMB client, something Apple may do.
post #24 of 43
Quote:
For OS X 10.7 Lion, Apple wrote its own software for Windows File Sharing under the name "SMBX" to replace Samba, adding initial support for Microsoft's SMB2 at the same time.

Though this has been widely reported, it isn't true. Support for SMB2 didn't exist in SMBX until now. Apple's decision to write their own SMB implementation was due to Samba's licensing change.

Ridiculous lucky captain rabbit king, lucky captain rabbit king nuggets are for the youth!
Reply
Ridiculous lucky captain rabbit king, lucky captain rabbit king nuggets are for the youth!
Reply
post #25 of 43
Quote:
Originally Posted by Superbass View Post

I think it's safe to anticipate this could cause a lot of growing pains, lots of reason to wait some months after release for the first "paying beta testers" to see how it pans out and gets patched.

Glad you mentioned that.  That's one of my biggest pet peeves.

 

Why do they keep announcing how many developers they have when it's clearly how many people are paying an extra $100 to test the latest software?

 

Common sense math would state that if there's 6 million developers then there should at least be 6 million apps?  Right?  I mean really?  ...and for those of you who will say "oh, the Mac!"... no.  ...and no.  No again!

 

There's supposedly 900,000 apps on the app store.  That would mean that each developer, even those who developed more than one app has made 0.15 apps.

 

Honestly the competition would use and literally embarrass them with that 6Mill number, if they had enough apps to make it a big deal.  Google might.  I don't know how many developers they have.

 

I don't know, but every time I hear the developer count followed by the app count I see the 0.15 apps per developer number.  It's hilarious!

 

Im not really sure, but if I was Tim and someone told me that we have 6Mil developers, and 900k apps I might ask a few more questions before I got up on stage an just announced that.  There should have been someone there in the "senior" staff that would at least say "What?  We can't say that!"

 

...add to this the time when Tallest Skill literally RANKED on a REAL developer who made a passbook app that was revolutionary.  (that never showed up after he was ranked on)

 

I love this site.


Edited by Vadania - 6/12/13 at 2:55am
post #26 of 43
Quote:
Originally Posted by motionlab-stuc View Post

For those asking, Time Machine can't be done over SMB - there is no decent Windows equivalent of a symbolic link or hard link and certainly no method of producing one over the SMB protocol.

Can you please clarify what you mean? You can create symbolic links in Windows, and you are create them over SMB2 and 3
post #27 of 43
Quote:
Originally Posted by jfanning View Post

Can you please clarify what you mean? You can create symbolic links in Windows, and you are create them over SMB2 and 3

The issue is hard links, not symbolic/soft links. There's a very important distinction which is vital to how Time Machine works - though as I'll explain later, this is all moot anyway.

 

A symbolic link is essentially a special type of file on the filesystem that points to another file somewhere else in the filesystem or even somewhere on another filesystem. It's similar to a shortcut in Windows or an alias in Mac OS 9, except that it operates at a slightly lower level in the stack, making it a bit more transparent to software. If you created a symbolic link called B to a file called A, most software would treat B as if it were A. However, if you deleted A (or even just rename it) B would break.

 

A hard link is more like a clone of the file, except that the data still resides in the same location. So if you create a hard link called B to a file called A, the entire software stack will treat both as if they're the actual file, but with separate metadata. What's really interesting about this is that if you delete A, B isn't affected at all. It keeps chugging along as if nothing happened because files are just pointers to the data, and the filesystem still sees B as a pointer to that data and leaves it alone.

 

That's the key to how Time Machine works. When it's doing a backup and finds a file hasn't changed, it just creates a hard link in the new backup to that same file in the previous backup. When the old backup is deleted, it doesn't have to be careful to move data around because the filesystem already takes care of that.

 

The catch here, however, is that any file sharing protocol (except maybe NFS) won't be able to understand the difference between a hard link and the original file anyway because they operate at a higher level than the filesystem. Most importantly, that means they can't create them. So now you should be wondering how Time Machine works over a network.

 

Abstraction! Time Machine hides all of this complex specialized filesystem work by placing the entire backup into a disk image (technically a sparse bundle, but the distinction isn't important here). All of the nitty gritty stuff is wrapped by the filesystem driver, so by the time it reaches the file sharing protocol it's nothing more than reading and writing data from a file. It doesn't need to support hard links, permissions, resource forks, or anything else like that.

 

In short, Time Machine's network backups requiring AFP is clearly something Mac-specific (though I'm not sure what), but it isn't hard links.


Edited by Ringo - 6/12/13 at 3:34am
Ridiculous lucky captain rabbit king, lucky captain rabbit king nuggets are for the youth!
Reply
Ridiculous lucky captain rabbit king, lucky captain rabbit king nuggets are for the youth!
Reply
post #28 of 43
Originally Posted by FreeRange View Post
NTFS support for read and write is also needed!

 

Not really, as long as each side has read support.

post #29 of 43

WTF! if this is true then I´m not switching to newer mac os versions in a LOOONG while... Ok their not removing it though sigh... Though the article is a bit missleading in the heading. It defaults to smb2.


Edited by habi - 6/12/13 at 6:02am
post #30 of 43
Quote:
Originally Posted by habi View Post

WTF! if this is true then I´m not switching to newer mac os versions in a LOOONG while...
 

No!  No!  No!  If you have Mountain Lion then this is Mountain Lion the way it was supposed to be.  It's literally everything that was missing.

 

I would suggest getting it.  If you have more than one display then I would say it's most definitely needed.

post #31 of 43

Read this article, see it mention something that happened more than a few years ago, scroll up. Yep, author is DED. Always good for "a brief history of..."

 

What's wrong with OS X including NTFS write support? It would obviate my need to run a WinXP virtual machine.

[this account has been abandoned]

Reply

[this account has been abandoned]

Reply
post #32 of 43
Quote:
Originally Posted by Vorsos View Post

Read this article, see it mention something that happened more than a few years ago, scroll up. Yep, author is DED. Always good for "a brief history of..."

 

What's wrong with OS X including NTFS write support? It would obviate my need to run a WinXP virtual machine.

Not really.  You would still need a VM or Boot Camp if you were to use most of the MS file formats.

 

It doesn't matter if you have NTFS or not, you're still not going to click on a Windows Media File and get it to play.  Amongst many others.

 

Even the new iCloud solution isn't getting around that.

post #33 of 43
Vadania View Post

Not really.  You would still need a VM or Boot Camp if you were to use most of the MS file formats.

It doesn't matter if you have NTFS or not, you're still not going to click on a Windows Media File and get it to play.  Amongst many others.

Even the new iCloud solution isn't getting around that.

 

File system ≠ file format.

 

I can already interact with "MS file formats," including WMV.

I want the ability to read and write to NTFS drives within the OS X environment. Make sense?

[this account has been abandoned]

Reply

[this account has been abandoned]

Reply
post #34 of 43
Quote:
Originally Posted by FreeRange View Post

NTFS support for read and write is also needed!

I don't believe this is something MS will license for use as part of competitor's OS.
post #35 of 43

Couldn't you just get Paragon NTFS for Mac?, works just fine here on 10.8.4
don't really see why it HAS to be Apple that licenses the driver, as long as it's there.

there's also open source alternatives, but paragon yield native NTFS speeds.

 

http://www.paragon-software.com/home/ntfs-mac/

post #36 of 43
Quote:

A hard link is more like a clone of the file, except that the data still resides in the same location. So if you create a hard link called B to a file called A, the entire software stack will treat both as if they're the actual file, but with separate metadata. What's really interesting about this is that if you delete A, B isn't affected at all. It keeps chugging along as if nothing happened because files are just pointers to the data, and the filesystem still sees B as a pointer to that data and leaves it alone.

 

That's the key to how Time Machine works. When it's doing a backup and finds a file hasn't changed, it just creates a hard link in the new backup to that same file in the previous backup. When the old backup is deleted, it doesn't have to be careful to move data around because the filesystem already takes care of that.

 

[...]

 

Abstraction! Time Machine hides all of this complex specialized filesystem work by placing the entire backup into a disk image (technically a sparse bundle, but the distinction isn't important here). All of the nitty gritty stuff is wrapped by the filesystem driver, so by the time it reaches the file sharing protocol it's nothing more than reading and writing data from a file. It doesn't need to support hard links, permissions, resource forks, or anything else like that.

 

In short, Time Machine's network backups requiring AFP is clearly something Mac-specific (though I'm not sure what), but it isn't hard links.

 

That's why a file system like ZFS with snapshot support would have been crucial: A snapshot creates a duplicate of the entire file system, but with copy-on-write semantics, so it's almost instantaneous. So each time machine backup would create a new snapshot, which would really freeze an instant in time. Then the same snapshot is made on the backup drive, and only the diffs would be copied over. Same space efficiency as what TimeMachine does, but without the directory hardlink hack, and no special permissions, etc. needed, i.e. the result would be something that could easily be restored with ASR.

 

Better, while a laptop is on the road, unlike the paltry mobile TM we have now, multiple local backups could be made, that then would simply be synced to the actual backup target once the mobile device is back at home. (Of course these mobile backups would only protect against accidental deletion, not drive failure, until they are synced to the backup at home).

 

ZFS would also have been error correcting/detecting and would allow for periodic data integrity checking, none of that is done in either NTFS or HFS+.

Both of these are similarly outdated.

 

We can only hope that Apple doesn't stop half-way and takes their LVM concept further to develop a true next generation file system on top of that.

post #37 of 43
The statement that "SMB2 is superfast" is a lie. The CIFS/SMB protocol is a clusterfuck of protocol overhead. NFS and AFP have way better bandwidth because they are not as talktative as SMB. Go ahead and test it.

About being more secure that also isn't totally true. Features like GSSAPI and rich ACLs (NFSv4 style) also exists on the NFSv4 protocol. But hey... kerberized nfsv4 doesn't really work on Mountain Lion and its nonexistant on previous versions.
post #38 of 43
I don't if saying it twice makes it truthful but the truth is it's really twice as fast 1smile.gif, I just did a direct comparison on a 2012 Mac mini and a 2013 MacBook Air, both running ML connected via a gigabit connection bounced through an apple time capsule to a Dell Server, both struggled to break past 50MB per second during large file transfers, I just installed the latest version of Mavericks and both machines are transferring the same data over the same network between 90MB to 105MB per second, I was really impressed, they have finally made some improvements to inter OS Networking.
post #39 of 43
Quote:
Originally Posted by kung-foo-kamel View Post

I don't if saying it twice makes it truthful but the truth is it's really twice as fast 1smile.gif, I just did a direct comparison on a 2012 Mac mini and a 2013 MacBook Air, both running ML connected via a gigabit connection bounced through an apple time capsule to a Dell Server, both struggled to break past 50MB per second during large file transfers, I just installed the latest version of Mavericks and both machines are transferring the same data over the same network between 90MB to 105MB per second, I was really impressed, they have finally made some improvements to inter OS Networking.

Im not shure I understand your test setup. Are you copying via afp to that dell server also? You can't make a judgment of speeds only to one platform saying that it's the protocols speed. There is a lot of things dependent in LANs and server/client configuration and hardware that have an influence on the outcome. And it's not aways the protocols fault.
post #40 of 43
Quote:
Originally Posted by Vadania View Post
 

Common sense math would state that if there's 6 million developers then there should at least be 6 million apps?  Right?  I mean really?  ...and for those of you who will say "oh, the Mac!"... no.  ...and no.  No again!

 

There's supposedly 900,000 apps on the app store.  That would mean that each developer, even those who developed more than one app has made 0.15 apps.

 

Honestly the competition would use and literally embarrass them with that 6Mill number, if they had enough apps to make it a big deal.  Google might.  I don't know how many developers they have.

 

I don't know, but every time I hear the developer count followed by the app count I see the 0.15 apps per developer number.  It's hilarious!

 

Im not really sure, but if I was Tim and someone told me that we have 6Mil developers, and 900k apps I might ask a few more questions before I got up on stage an just announced that.  There should have been someone there in the "senior" staff that would at least say "What?  We can't say that!"

 

Um, in many cases, apps are made by multiple developers. Apps by Facebook, Google, Microsoft, Instagram and many other big name apps are made by multiple people.

 

The lone developer making an app and making it rich is the exception, not the rule.

New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Mac OS X
AppleInsider › Forums › Software › Mac OS X › Apple shifts from AFP file sharing to SMB2 in OS X 10.9 Mavericks