8 ms·

New OS X uses Windows file sharing by default

178 points by nkhumphreys 13y ago

velodrome 13y ago
This is great. I can finally interoperate with linux and windows. Every time I connect with AFP, my CPU would spike to 100% under Ubuntu.
- lysol 13y ago
  This isn't new functionality, it's just that SMB2 is now the default.
  - velodrome 13y ago
    I heard it was kind of buggy in 10.8.x.
    - TillE 13y ago
      I did need to tweak some registry setting on my Win7 box to allow my MacBook to access its shares properly. Not very user-friendly, but after that it's worked fine.
    - deathcakes 13y ago
      Buggy is not nearly strong enough - supporting lots of mixed environments has given me ragequit levels of stress, precisely because Apple dropped samba and decided to write their own.
      - alayne 13y ago
        Why are people doing so much peer level file sharing anyway? Performance? Security? In a company it would be a lot better to have centralized servers with high availability, probably with some kind of web-based CMS to store files, something like Confluence or Sharepoint.
        lmm 13y ago
        How so? FS-level sharing is easy to use (it's just a drive that's the same on everyone's machine) and the workflow is a lot more efficient if you're using a conventional application to edit the files. It performs pretty well, and integrates nicely with AD/Kerberos for security. As long as there's a decent versioning/backup policy in place (which can be handled by the server admins, users don't have to worry about it) what's the problem?
        elithrar 13y ago
        > Why are people doing so much peer level file sharing anyway? Performance? Security? In a company it would be a lot better to have centralized servers with high availability, probably with some kind of web-based CMS to store files, something like Confluence or Sharepoint. You have to assume that the majority of Apple's users are home/edu/SMB users, who don't have centralised infrastructure. They just want to share files between each other, or from a small NAS. Those who have Macs in an enterprise environment likely have a working solution via other methods.
        deathcakes 13y ago
        Because not everyone is running a server cabinet filled to the brim with high performance kit and a gigabit internet connection. A lot of small companies have limited resources and limited experience and it turns out that peer level file sharing is the easiest way to do what they need, which is share files between themselves.
  - vvhn 13y ago
    from a functionality point of view yes - you have always been able to connect to a Linux/BSD box using NFS, SMB(1) ( if samba is installed on them ) or AFP ( if netatalk is installed on them ). What this thing is saying SMB2 support has been added ( since Mountain Lion does not support SMB2 ) and seems to have been simultaneously made the default for connecting to servers that support it ( hopefully only if you don't explicitly specify what to use and presumably the SMB server on OS X Mavericks does )
apitaru 13y ago
Finally. Someone at Apple must be a Bukowski fan. I'm reminded of his poem "16 Bit Intel 8088 Chip" (not his greatest, but suitable): http://bukowskiforum.com/threads/16-bit-intel-8088-chip.2791/ http://bukowskiforum.com/threads/16-bit-intel-8088-chip.2791...
- cpach 13y ago
  I had never heard of that poem before, I think it’s awesome :)
onedognight 13y ago
> Time Machine, only works over a LAN with destinations that support AFP. This is at least in part because of Time Machine's reliance on Unix hard links, and also in part because it has to be able to ensure that any OS X files with HFS+ specific metadata are correctly preserved. This is not the reason. Time Machine does support hard links, legacy Mac metadata, and other Unix features. It does this by writing all the data into large blobs (a sparse bundle) with an embedded filesystem of its choosing (i.e. HFS+). It can use any destination filesystem for the blobs, including FAT.
- r00fus 13y ago
  by "large blobs" you mean sparsebundles, right? Sparsebundles (as opposed to diskimages) can be diff'd allowing Time Machine to not only treat them as an HFS capable FS, but to isolate changes to a single block, reducing network traffic and time to backup.
  - glhaynes 13y ago
    Sparsebundles aren't diffed in Time Machine (what would they diff against?); and backups are only done in whole-file increments, not at a block level.
    - mapgrep 13y ago
      >backups are only done in whole-file increments, not at a block level OP seems to refer to how the Time Machine destination backup file is chunked when using a sparsebundle, such that individual chunks can be updated in isolation, which is how Time Machine came to support network backups. Previously, Time Machine's destination file was a monolithic disk image that had to be updated in whole, which would be unrealistic for network backups. At a filesystem level, a sparsebundle is just a directory and the chunks are individual data files, which the OS coalesces into a single logical file. Sparsebundles appear as individual "files" in the Finder but you can right click to see the individual chunk files. A sparsebundle is effectively a "blob" as GP states, since it is designed to contain arbitrary data, and since it's implemented with the most rudimentary filesystem components it works across platforms as GP also states. But when discussing network transfers it makes sense to think if it as a simple collection files rather than a "blob." (OP describes the chunks as "blocks" but that implies hard drive blocks which is not the case.)
inthewind 13y ago
Can someone chime in, with the pros and cons of each network filesystem. And which is a good fit for Linux - or rather for those OSs that don't need to cooperate with Windows? Was NFS ever updated - or replaced? How much of SMB is now open after court rulings? And is their one that is technically better than another?
- nvr219 13y ago
  Use ReiserFS
  - Demiurge 13y ago
    I heard it's a killer.
  - inthewind 13y ago
    Is ReiserFS a network file system?
- astrodust 13y ago
  NFS was never especially good, many a system admin would spend hours upon hours trying to fix it when it malfunctioned for no specific reason, but it was just the only viable option for many years. The alternatives were either research projects, or proprietary protocols like Novell used. SMB isn't so much better as more widely supported.
  - lmm 13y ago
    SMB at least avoids the stupid NFS behaviour where any program that tries to read while the server's offline uninterruptibly hangs.
    - nitrogen 13y ago
      That's a configurable option (mount -o soft). On Ubuntu, the nfs(5) manpage has more information. This option is a good thing in a strict client/server scenario where the client should not lose data even if the server is rebooted. Years ago I watched an NFS mount in an old broadcast video setup recover unimpeded after its target system was rebooted.
codex 13y ago
I would have preferred NFSv4 over SMB2. They are quite similar technically, but the former has less chance of veering off into supporting strange Windowsims which will be hard to translate to a POSIX client. That said, SMB2 is widely deployed and Microsoft is innovating in SMB faster than NFS is improving. Fortunately OS X does not use Samba as their SMB2 client.
- mhurron 13y ago
  Most users are going to have a Mac and a Windows machine, SMB makes far more sense. You're going to see NFS in enterprise situations and Apple does not really aim there target there.
  - mitchty 13y ago
    Not only that but nfsv4 has its own issues in regards to userid/gid mapping. Setting that up with kerberos is... not fun (speaking from the solaris/linux/aix side of things). Not that smb would be better for most unixes mind you, just that nfsv4 is its own version of hell in some ways.
polshaw 13y ago
Related: I take it there is no maintained open source SMB server that isn't GPL3 these days? Sucks since apple abandoned samba2. How stupid would it be to use apple's old samba2 for an appliance? (guess: very?)
- lmm 13y ago
  Can you not just install modern samba yourself?
  - icebraining 13y ago
    I'd guess polshaw wants to sell/distribute an appliance containing proprietary software (hence the reluctance to use a GPLv3 licensed component), not just install it on his own device.
    - jra_samba_org 13y ago
      No, polshaw sounds like he has religious reasons against GPLv3 (as do Apple :-). There are many people shipping Samba on an appliance containing proprietary software, there is no problem doing that with GPLv3 code.
      - polshaw 13y ago
        Hi there, hopefully you will still see this.. No religious objection. The problem for me with GPLv3 is that it is not compatible with (privately) signed code. If it is possible to run unsigned code on my appliance then my proprietary code would not be secure, putting the entire business in jeopardy. If you can square this circle then I'd love to use it. I'd be interested to see a list of shipping appliances (meaning not open hardware platforms) with GPLv3 if you know of any.
        jra_samba_org 13y ago
        By "signed" do you mean a DRM-locked down platform ? There's no problem with signed code, there is a problem with trying to claim ownership of a device that the customer owns :-). There are many appliances shipping with GPLv3 Samba, Netgear, Drobo, IOmega, Synology, just off the top of my head. Of course none of these are trying to control what the customer does with the appliance. If you want to control what customers do with their own hardware, write your own SMB3 server. Good luck with that..
rogerbinns 13y ago
SMB has an extension mechanism and SMB 1 has support for Unix extensions for over 15 years - I was the author of the original Unix extensions spec. You can get full Unix semantics using them (links etc). The predominant form of extension is an "info level". Somewhat analogous to a data structure like that returned from stat, the numeric info level controls what structure is returned (or supplied). Microsoft had a tendency to add new info levels that correspond to whatever the in-kernel data structures were in a particular release rather than longer term good design. The general chattiness comes from their terrible clients like Windows Explorer (akin to Finder for Mac folk). I once did a test opening a zip file using using Explorer. If you hand crafted the requests it would have 5 of them - open the file, get the size, read the zip directory from the end of the file, close it. Windows XP sent 1,500 requests and waited synchronously for each one to finish. Windows Vista sent 3,000 but the majority were asynchronous so the total elapsed time was similar. I worked on WAN accelerators for a while where you can cache, read ahead and write behind, in order to provide LAN performance despite going over WAN links. In one example a 75kb Word memo was opened over a simulated link between Indonesia and California. It took over two minutes - while instantaneous with a WAN accelerator. The I/O block size with SMB is 64kb so they could have got the entire file in two reads, but didn't. If anyone is curious about what it was like writing a SMB server in the second half of the nineties I wrote about it at http://www.rogerbinns.com/visionfs.html http://www.rogerbinns.com/visionfs.html
- michael_miller 13y ago
  Do you know the cause of the 3k requests which Vista made? Do you have a sane theory why these were occurring? Also, do you have any suggestions for better clients to use?
  - rogerbinns 13y ago
    > Do you know the cause of the 3k requests which Vista made? Do you have a sane theory why these were occurring? Backwards compatibility and layers of indirection. Microsoft has always made great efforts for backwards compatibility - Raymond Chen's blog is a good source of stories. Quite simply if you upgraded Windows and apps stopped working then you'd blame Windows. Of course it is almost always the apps relying on undocumented behaviour, ignoring documentation, relying on implementation artifacts etc. This means a lot of code to detect and work around problems in other components. For a networked filesystem client the simplest way is sending lots of requests and picking results of interest based on what comes back. Networked filesystem servers also work around client problems in various ways - eg they may return smaller block sizes than the client requested because it is known to have occasional problems. All of this builds up layers and layers of workarounds, workarounds to workarounds, having to test against OS/2 etc. SMB2 was an attempt to wipe the slate clean (no more OS/2!) but of course the crud starts building up again. Explorer isn't a program that displays files and directories despite appearances. There are layers and layers of abstractions, parts provided by COM etc. The code that knows it wants to display the listing of a zip file is many layers away from the code that generates network requests. It is always easier to write code that does more than strictly needed than the absolute minimum necessary.
zwieback 13y ago
Back in the early nineties I worked at Miramar Systems on an AFP server and actually a full AppleTalk stack that ran on Windows 3.11 (VxDs!) and OS/2. Macs could run full AFP and whatever the printer protocol was called to a network of PCs. IBM sold a version of our stuff that was called LanServer for Macintosh so back then Macs and AFP were covered! It was quite a popular product at the time. Although I never enjoyed working on Macs I thought that AFP was pretty cool. We all had "Inside AppleTalk" pretty much memorised - what a great book.
shinratdr 13y ago
I'm hoping this results in vastly improved SMB support, which I am in full agreement with other commenters, has been infuriating since Apple decided to roll their own. I frequently hop to my Windows machine to manage my Windows Home Server even though I'm just doing simple SMB communication and file cleanups that should work fine in OS X, but don't.
sytelus 13y ago
OS X's interchangeability with PCs is actually more badly broken than this. This is mind boggling because if Apple can get this one thing right more people would be willing to buy Mac Mini and put on their home networks. I recently tried to use external device full of NTFS formatted hard drives on Mac Mini. First thing I discovered was that OS X can't natively write to NTFS formatted drives. Even after you discover and purchase 3rd party apps that enables writing to NTFS formatted volumes, OS X can't share them via SMB. This is because Apple's own SMB implementation that they tried to replace is broken. So you have to disable that and install open source SMB anyway. There are quite a bit of hoops to accomplish this. So there is no built-in way to share your external drives connected to Mac Mini on network if they are NTFS formatted.

178 points by nkhumphreys 13y ago

This is great. I can finally interoperate with linux and windows. Every time I connect with AFP, my CPU would spike to 100% under Ubuntu.

lysol 13y ago
This isn't new functionality, it's just that SMB2 is now the default.
- velodrome 13y ago
  I heard it was kind of buggy in 10.8.x.
  - TillE 13y ago
    I did need to tweak some registry setting on my Win7 box to allow my MacBook to access its shares properly. Not very user-friendly, but after that it's worked fine.
  - deathcakes 13y ago
    Buggy is not nearly strong enough - supporting lots of mixed environments has given me ragequit levels of stress, precisely because Apple dropped samba and decided to write their own.
    - alayne 13y ago
      Why are people doing so much peer level file sharing anyway? Performance? Security? In a company it would be a lot better to have centralized servers with high availability, probably with some kind of web-based CMS to store files, something like Confluence or Sharepoint.
      - lmm 13y ago
        How so? FS-level sharing is easy to use (it's just a drive that's the same on everyone's machine) and the workflow is a lot more efficient if you're using a conventional application to edit the files. It performs pretty well, and integrates nicely with AD/Kerberos for security. As long as there's a decent versioning/backup policy in place (which can be handled by the server admins, users don't have to worry about it) what's the problem?
      - elithrar 13y ago
        > Why are people doing so much peer level file sharing anyway? Performance? Security? In a company it would be a lot better to have centralized servers with high availability, probably with some kind of web-based CMS to store files, something like Confluence or Sharepoint. You have to assume that the majority of Apple's users are home/edu/SMB users, who don't have centralised infrastructure. They just want to share files between each other, or from a small NAS. Those who have Macs in an enterprise environment likely have a working solution via other methods.
      - deathcakes 13y ago
        Because not everyone is running a server cabinet filled to the brim with high performance kit and a gigabit internet connection. A lot of small companies have limited resources and limited experience and it turns out that peer level file sharing is the easiest way to do what they need, which is share files between themselves.
- vvhn 13y ago
  from a functionality point of view yes - you have always been able to connect to a Linux/BSD box using NFS, SMB(1) ( if samba is installed on them ) or AFP ( if netatalk is installed on them ). What this thing is saying SMB2 support has been added ( since Mountain Lion does not support SMB2 ) and seems to have been simultaneously made the default for connecting to servers that support it ( hopefully only if you don't explicitly specify what to use and presumably the SMB server on OS X Mavericks does )

apitaru 13y ago

Finally. Someone at Apple must be a Bukowski fan. I'm reminded of his poem "16 Bit Intel 8088 Chip" (not his greatest, but suitable): http://bukowskiforum.com/threads/16-bit-intel-8088-chip.2791/ http://bukowskiforum.com/threads/16-bit-intel-8088-chip.2791...

cpach 13y ago
I had never heard of that poem before, I think it’s awesome :)

onedognight 13y ago

> Time Machine, only works over a LAN with destinations that support AFP. This is at least in part because of Time Machine's reliance on Unix hard links, and also in part because it has to be able to ensure that any OS X files with HFS+ specific metadata are correctly preserved. This is not the reason. Time Machine does support hard links, legacy Mac metadata, and other Unix features. It does this by writing all the data into large blobs (a sparse bundle) with an embedded filesystem of its choosing (i.e. HFS+). It can use any destination filesystem for the blobs, including FAT.

r00fus 13y ago
by "large blobs" you mean sparsebundles, right? Sparsebundles (as opposed to diskimages) can be diff'd allowing Time Machine to not only treat them as an HFS capable FS, but to isolate changes to a single block, reducing network traffic and time to backup.
- glhaynes 13y ago
  Sparsebundles aren't diffed in Time Machine (what would they diff against?); and backups are only done in whole-file increments, not at a block level.
  - mapgrep 13y ago
    >backups are only done in whole-file increments, not at a block level OP seems to refer to how the Time Machine destination backup file is chunked when using a sparsebundle, such that individual chunks can be updated in isolation, which is how Time Machine came to support network backups. Previously, Time Machine's destination file was a monolithic disk image that had to be updated in whole, which would be unrealistic for network backups. At a filesystem level, a sparsebundle is just a directory and the chunks are individual data files, which the OS coalesces into a single logical file. Sparsebundles appear as individual "files" in the Finder but you can right click to see the individual chunk files. A sparsebundle is effectively a "blob" as GP states, since it is designed to contain arbitrary data, and since it's implemented with the most rudimentary filesystem components it works across platforms as GP also states. But when discussing network transfers it makes sense to think if it as a simple collection files rather than a "blob." (OP describes the chunks as "blocks" but that implies hard drive blocks which is not the case.)

inthewind 13y ago

Can someone chime in, with the pros and cons of each network filesystem. And which is a good fit for Linux - or rather for those OSs that don't need to cooperate with Windows? Was NFS ever updated - or replaced? How much of SMB is now open after court rulings? And is their one that is technically better than another?

nvr219 13y ago
Use ReiserFS
- Demiurge 13y ago
  I heard it's a killer.
- inthewind 13y ago
  Is ReiserFS a network file system?
astrodust 13y ago
NFS was never especially good, many a system admin would spend hours upon hours trying to fix it when it malfunctioned for no specific reason, but it was just the only viable option for many years. The alternatives were either research projects, or proprietary protocols like Novell used. SMB isn't so much better as more widely supported.
- lmm 13y ago
  SMB at least avoids the stupid NFS behaviour where any program that tries to read while the server's offline uninterruptibly hangs.
  - nitrogen 13y ago
    That's a configurable option (mount -o soft). On Ubuntu, the nfs(5) manpage has more information. This option is a good thing in a strict client/server scenario where the client should not lose data even if the server is rebooted. Years ago I watched an NFS mount in an old broadcast video setup recover unimpeded after its target system was rebooted.

codex 13y ago

I would have preferred NFSv4 over SMB2. They are quite similar technically, but the former has less chance of veering off into supporting strange Windowsims which will be hard to translate to a POSIX client. That said, SMB2 is widely deployed and Microsoft is innovating in SMB faster than NFS is improving. Fortunately OS X does not use Samba as their SMB2 client.

mhurron 13y ago
Most users are going to have a Mac and a Windows machine, SMB makes far more sense. You're going to see NFS in enterprise situations and Apple does not really aim there target there.
- mitchty 13y ago
  Not only that but nfsv4 has its own issues in regards to userid/gid mapping. Setting that up with kerberos is... not fun (speaking from the solaris/linux/aix side of things). Not that smb would be better for most unixes mind you, just that nfsv4 is its own version of hell in some ways.

polshaw 13y ago

Related: I take it there is no maintained open source SMB server that isn't GPL3 these days? Sucks since apple abandoned samba2. How stupid would it be to use apple's old samba2 for an appliance? (guess: very?)

lmm 13y ago
Can you not just install modern samba yourself?
- icebraining 13y ago
  I'd guess polshaw wants to sell/distribute an appliance containing proprietary software (hence the reluctance to use a GPLv3 licensed component), not just install it on his own device.
  - jra_samba_org 13y ago
    No, polshaw sounds like he has religious reasons against GPLv3 (as do Apple :-). There are many people shipping Samba on an appliance containing proprietary software, there is no problem doing that with GPLv3 code.
    - polshaw 13y ago
      Hi there, hopefully you will still see this.. No religious objection. The problem for me with GPLv3 is that it is not compatible with (privately) signed code. If it is possible to run unsigned code on my appliance then my proprietary code would not be secure, putting the entire business in jeopardy. If you can square this circle then I'd love to use it. I'd be interested to see a list of shipping appliances (meaning not open hardware platforms) with GPLv3 if you know of any.
      - jra_samba_org 13y ago
        By "signed" do you mean a DRM-locked down platform ? There's no problem with signed code, there is a problem with trying to claim ownership of a device that the customer owns :-). There are many appliances shipping with GPLv3 Samba, Netgear, Drobo, IOmega, Synology, just off the top of my head. Of course none of these are trying to control what the customer does with the appliance. If you want to control what customers do with their own hardware, write your own SMB3 server. Good luck with that..

rogerbinns 13y ago

SMB has an extension mechanism and SMB 1 has support for Unix extensions for over 15 years - I was the author of the original Unix extensions spec. You can get full Unix semantics using them (links etc). The predominant form of extension is an "info level". Somewhat analogous to a data structure like that returned from stat, the numeric info level controls what structure is returned (or supplied). Microsoft had a tendency to add new info levels that correspond to whatever the in-kernel data structures were in a particular release rather than longer term good design. The general chattiness comes from their terrible clients like Windows Explorer (akin to Finder for Mac folk). I once did a test opening a zip file using using Explorer. If you hand crafted the requests it would have 5 of them - open the file, get the size, read the zip directory from the end of the file, close it. Windows XP sent 1,500 requests and waited synchronously for each one to finish. Windows Vista sent 3,000 but the majority were asynchronous so the total elapsed time was similar. I worked on WAN accelerators for a while where you can cache, read ahead and write behind, in order to provide LAN performance despite going over WAN links. In one example a 75kb Word memo was opened over a simulated link between Indonesia and California. It took over two minutes - while instantaneous with a WAN accelerator. The I/O block size with SMB is 64kb so they could have got the entire file in two reads, but didn't. If anyone is curious about what it was like writing a SMB server in the second half of the nineties I wrote about it at http://www.rogerbinns.com/visionfs.html http://www.rogerbinns.com/visionfs.html

michael_miller 13y ago
Do you know the cause of the 3k requests which Vista made? Do you have a sane theory why these were occurring? Also, do you have any suggestions for better clients to use?
- rogerbinns 13y ago
  > Do you know the cause of the 3k requests which Vista made? Do you have a sane theory why these were occurring? Backwards compatibility and layers of indirection. Microsoft has always made great efforts for backwards compatibility - Raymond Chen's blog is a good source of stories. Quite simply if you upgraded Windows and apps stopped working then you'd blame Windows. Of course it is almost always the apps relying on undocumented behaviour, ignoring documentation, relying on implementation artifacts etc. This means a lot of code to detect and work around problems in other components. For a networked filesystem client the simplest way is sending lots of requests and picking results of interest based on what comes back. Networked filesystem servers also work around client problems in various ways - eg they may return smaller block sizes than the client requested because it is known to have occasional problems. All of this builds up layers and layers of workarounds, workarounds to workarounds, having to test against OS/2 etc. SMB2 was an attempt to wipe the slate clean (no more OS/2!) but of course the crud starts building up again. Explorer isn't a program that displays files and directories despite appearances. There are layers and layers of abstractions, parts provided by COM etc. The code that knows it wants to display the listing of a zip file is many layers away from the code that generates network requests. It is always easier to write code that does more than strictly needed than the absolute minimum necessary.

zwieback 13y ago

Back in the early nineties I worked at Miramar Systems on an AFP server and actually a full AppleTalk stack that ran on Windows 3.11 (VxDs!) and OS/2. Macs could run full AFP and whatever the printer protocol was called to a network of PCs. IBM sold a version of our stuff that was called LanServer for Macintosh so back then Macs and AFP were covered! It was quite a popular product at the time. Although I never enjoyed working on Macs I thought that AFP was pretty cool. We all had "Inside AppleTalk" pretty much memorised - what a great book.

shinratdr 13y ago

I'm hoping this results in vastly improved SMB support, which I am in full agreement with other commenters, has been infuriating since Apple decided to roll their own. I frequently hop to my Windows machine to manage my Windows Home Server even though I'm just doing simple SMB communication and file cleanups that should work fine in OS X, but don't.

sytelus 13y ago

OS X's interchangeability with PCs is actually more badly broken than this. This is mind boggling because if Apple can get this one thing right more people would be willing to buy Mac Mini and put on their home networks. I recently tried to use external device full of NTFS formatted hard drives on Mac Mini. First thing I discovered was that OS X can't natively write to NTFS formatted drives. Even after you discover and purchase 3rd party apps that enables writing to NTFS formatted volumes, OS X can't share them via SMB. This is because Apple's own SMB implementation that they tried to replace is broken. So you have to disable that and install open source SMB anyway. There are quite a bit of hoops to accomplish this. So there is no built-in way to share your external drives connected to Mac Mini on network if they are NTFS formatted.