10.9.2 Mavericks and can no longer connect to our SMB file share on the network.

Same story here - smb:// worked under 10.9.1, but the Update 10.9.2 broke it.

Some facts:

• Mac Book Pro Retina 2012
• Network connection is over WLAN (The connection is very stable and no issues else where)
• The issue seems to be caused when there are larger files (> 500MB) in the share
• smb:// works for shares with lots of folders but only small files in them
• smb:// and cifs:// are both almost unusable
• smb:// shows a blank screen for ages- Finder will eventually hang up
• cifs:// will connect fast (wow!), but the connection is very unstable for larger files

The funny part is, that Mavericks (pre 10.9.2) was the first OS X which fixed most SMB issues of its predecessor. (SMB2 was somwhat slow, but quite usable) Now, I can not really use my Mac to work...

Moral of the story, I think I will switch to Ubuntu 14 when it is released in April - it should support HDPI Displays.

I had the same problems with my new Retina MBP and found this crazy (but working) solution:

http://blog.helloyama.com/post/77813860132/replacing-the-os-x-10-9-mavericks-smb -stack-with

For convenience I repost this blogpost here:

Replacing the OS X 10.9 (Mavericks) SMB Stack with Samba3

A couple months back, I was excited to hear that Apple was working on a new SMB stack for their new operating system, OS X 10.9. However, once it finally hit, I realized that the new stack was even worse than the old one. I was unable to mount CIFS or SMB shares on our local storage cluster (a lovely 2 petabyte capacity Isilon cluster), getting error messages in system logs that looked like the following:

2/24/14 2:47:34.000 PM kernel[0]: smb_smb_ssnsetup: HOSTNAME doesn’t support extended security, this server will be deprecated in the future!

I started to wonder if replacing Apple’s stack with the SMB stack provided by Sambawould be a good idea. It was. If you are using any storage appliance and have found that your SMB/CIFS access has been effectively cut off, or that it’s incredibly slow, read the following steps to replace your SMB stack in OS X.

1. Install Homebrew - Using OS X as a sysadm has been mostly a blessing, but sometimes a curse. OS X has a great BSD based core and ships with many utilities found in other *nixes, but more than often those versions have various nuances that make me want to switch to the GNU provided versions. Homebrew allows you to download packages simply by running a ‘brew install programname’ in the Terminal. (After installing Homebrew, make sure you run a ‘sudo vim /etc/paths’ and move ‘/usr/local/bin’ to the top. This places /usr/local/bin in a higher priority when your system searches your $PATH for whatever binary you’re trying to execute.
   
2. Once you have Homebrew installed (make sure you run ‘brew doctor’ to ensure all dependencies are installed)
   
3. Next, install the Homebrew provided version of Samba. Currently, the version is at 3.6.20 (the command should be ‘brew install samba’)
   
4. Homebrew will install this version of Samba to /usr/local/Cellar/samba/3.6.20 — if you aren’t familiar with the history of the /usr/local directory, read this) (if you understand the purpose of /usr/local, you’ll realize that installing here is completely safe and will not overwrite any of your operating system’s components). Homebrew creates a symlink to any binaries made in the /usr/local/bin and /usr/local/sbin folders.
   
5. Next, we need to unload Apple’s netbios and samba daemons (Daemons is another term for services in the *nix world).
   sudo launchctl stop com.apple.netbiosdsudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.netbiosd.plist
   
6. Next, we need to create plist files that point to the new versions of smbd andnmbd. These files will need to be created in /Library/LaunchDaemons/ — the contents and names of the files should be match the following (notice the location of the smbd and nmbd binaries — /usr/local/sbin/, where smbd and nmbd are symlinked to their respective binaries at /usr/local/Cellar/samba/3.6.20):
   org.samba.smbd.plist
   org.samba.nmbd.plist
   (I’m currently experimenting with the -D and -F flags for both of these services. For a description of the flags, check out the man pages for the respective service)
7. Now that you have the services’ plist files ready, go ahead and launch them.
   sudo launchctl load /Library/LaunchDaemons/org.samba.smbd.plistsudo launchctl load /Library/LaunchDaemons/org.samba.nmbd.plist
8. If you don’t have any shares currently open, the changes should take effect immediately. However, I highly suggest a restart after this process.
   
9. Enjoy your new SMB3 stack! Immediately I noticed MUCH faster transfer speeds. Example: Grabbed a 900MB ISO off of a share in 6 seconds!

I see 3 issues here:

1. Cannot connect to an 'smb' share at all
2. Cannot use previously defined Mac 'aliases' to connect/navigate to Windows directories
3. Slow performance using 'smb' with some flavour of 'Mavericks' (10.9.x)

Issues 1 and 2 may well go together. Our problem in our company was this:

Fleet of 80 + Mac users running Mountain Lion (10.8.x) worked well getting to 'smb' shares and directories. They had setup aliases on their Mac Desktops to gain quick access to these.

An upgrade project to move these users to Mavericks meant that these aliases no longer worked. Nor would a direct path connection.

The below is an example of what would be entered into the 'Connect to Server...' dialog:

smb://servername.domain.com/Users/username

Under Mavericks, there would be a mount achieved but then an empty finder window and perhaps a message pointing to insufficient permissions.

With collaboration of our Windows server guys, we found that Mavericks has a problem with 'traverse folder' permissions. Our directory structure was designed to not allow the users to see the contents of the parent folder of the one they are navigating to ( "Users" in the above path example ). Mavericks can take you directly to where you have permission, as long as you use the 'Connect to Server...' method. This is cumbersome as referring back to this mounted directory later means going back to the Finder to reinitiate the connection, and of course aliases/shortcuts won't work.

As of this writing, there is no fix for this, unless the Windows permissions are to be modified on the Server. Yosemite seems to return to the behaviour of Mountain Lion.

I have no comments or further tests made at this point regarding point 3 with the slower performance.

I hope this helps and clears up for some folks. There are no doubt going to be differences depending on whether you are in an Enterprise, small business or at home. The core similarity is the connecting to Windows shares.

Yes my smb is not working

Since i upgraded to 10.9.2 i cant access network shares

It shows them empty or thriple directories

My operating system is becoming very unstable

This is the first time this has happened from an update

DO NOT UPDATE ITS REALLY BAD

You will find many posting regarding SMB2 connections since 10.9.2. I'm affect too. There are some workarounds floating through the forum but in reality it doesn't work. So we will have to wait until Apple is thinking this is a priority issue.

Did some snooping around and found this (thanks to the tip of surogat70 that this could be SMB2 related) -> http://hints.macworld.com/article.php?story=20131122083837447

You can change the new default system behavior that uses SMB2 protocol back to SMB. Seems to work for me anyways. I can mount my network drives again.

Not very stabile though. The disks unmount themself's after a certain time not being used it seems.

I can life with it for now. But please fix this ASAP Apple. It seems that it becomes a trend that with every "up"date of osx something very essential for me is breaking. It's becoming a nuisance.

I didn't know about the SMB situation before this. But being able to browse network storage is for some mission critical! Don't implement new protocols that aren't fully and reliably working.

Sorry don't have any tips for you. But I also have a lot of trouble with the "quicklook" function when using it on network storage.

If I use quicklook on a file (.pdf, .mp3, mp4, txt, etc, etc, etc), the finder instantly crashes. This is a serious disturbance in my workflow.

Reading your problem I think these two are related (although I didn't check logfiles, at the moment I have a little bit of a "why bother" attitude towards Apple bugs).

Apple spent so many years to build themselves up, to challenge the pc market

Five mistakes which puts their head in the sand

1) 10.6 Rosetta gone

2) Java so screwed

3) Server going down hill

4) New OS every year

5) This smb issue

Even like the ipad no flash - Why????

We do our head in for third party apps

Really starting to consider the pc

I might suggest it to all my work sites to stay clear from apple

Being a network administrator for 5 sites, there issues become my

Apple do yourself a favour & really think about what your doing?

What you have achieved & stop acting like top cop.

Your product is good but not that good

I been using Windows 8.1 but you install the classic shell & it works really really well.

I have a new information regarding this problem. After some communication with an Apple support engineer through the Bug Reporting tool I figured out that something is wrong with existent share connections. To be more clear, I suspect that after the update to 10.9.2 some login features have changed. Furthermore it seems that there is a problem with accessing shares through fully qualified domain names.

My suggestion for all affect by this problem is to delete all key chains related to SMB shares and also delete all known server connections. After reboot create a new share connection with the IP (not the fully qualified domain name) to the server and enter the credentials again.

Report here back if that is working.

Edit: Use the new server connection notation for connections:

smb://admin@192.168.0.1/share1

As in the example above.

First of I really want to say this (and this is a comment towards Apple not you surogat70!). How can there be something wrong with an exciting network connection? Is it something like "your holding your phone wrong?" Not here to attack someone, but Apple broke something. FIX IT!

As an reply to surogat: yes I did all you suggest. Deleted all know connection, and tried to get it going again.

After the "hack" I shared in this thread things seems to be "working", but very, very buggy. Network shares keep unmounting. Copying files is a nightmare, it's slow and it's more of a guess than certainty what permissions they have. Finder crashes, can't use quicklook. The "it just works" philosophy is fubar at the moment.

I only come to this forum if a got a real problem, which I can't solve even after many, many years of osx use.

I tried to directly use IP and specifiy the user name in order to connect to the SMB, it does not solve the problem. However, it worked very fast for one day (about 1 hour usage) but the next day it eventually ended up being very slow.

However, I noticed also some strange network "lags" outside the smb/smb2/cifs recently. For example, if I access a LAN Http Webserver (even when directly specify the IP), it sometimes takes quite a while to display a (small) plain text page. No other device has any issues with it - and mostly, the rMBP works also.

Further, while I ran some tests with Safari and connecting to the local http server, I noticed that windows domain name resolution shows really strange behaviour. The first time, it resolves the computer name instant to its IP, two minutes later it takes about 30 seconds. One would expect the opposite behaviour due to caching... Sometimes it is instant, sometimes it takes quite a while.

While I did those Http and name resolution tests, I was measuring network pings, yet I could not find any evidence of network drops. In fact, the connection was very stable.

I dont know whats wrong with OSX network stack, but there clearly are issues.

Note: All my tests and measurings were made using the wireless adapter.

Dseif's suggestion of using cifs:// to mount, solves the issue for me as well.

When I use smb:// to mount local Windows shares over a wired connection, the mount itself happens right away, but can take minutes before I can see files and folders. Once I can see them, navigating within them seems to be normal. Mounts to different shares on the same server also seem normal, as long as I leave at least one share mounted to that server. If I unmount them all, a new mount will again take minutes, before I can see files and folders again.

Oddly, when I use smb:// to mount a remote Windows share (~25ms latency through a VPN tunnel), I don't experience the same delays...the response seems the same as when using cifs://

Both the local and remote Windows servers I'm connecting to are running Windows Server 2012 R2, which I believe use SMB 3.0.

An other bug I believe related to this SMB2 thing, is that almost all my alias folders on the networked storage are broken.

It came to my attention when a old client contacted me in a panic. I set up a workflow for her, which worked for 5 years prior, with aliased folders, a lot of them. Almost nothing worked!

Can't restore the aliased folders because of permission issues (although "everyone" has read and write permissions). The same permission error can be said for some none aliased folders. Those permission issues (I'm not willing to investigate further) are persistent even when I revert my (clients) system(s) back to 10.8.

Thanks Apple, you just gave me days of work. Without pay though, client has no more money to spend. I want to keep the relations good, so I can't say no really.

After upgrading to Mavericks OS X 10.9.2, I could not connect to network shares on a Windows network, and kept getting "Connection Failed" errors every time I tried to connect. But I finally found a solution.

Firstly, using Finder --> Go --> Connect To Server --> smb://server_address --> Connect did not work. As suggested by others, I also tried cifs://server_address and that did not work either.

What worked for me was to use a Windows PC's cmd window to find the actaul IP address of the network share I am trying to reach. Example, "ping server_address". Once I found out the actual IP address of the network share, then I used it in the Finder. like this:

Finder --> Go --> Connect To Server --> smb://192.168.xxx.xxx --> Connect. When I did this, then I got a prompt to pick which volumes I want to mount. Voila, the server_address I was trying to reach was now mounted as a Share in my Finder.

I guess the only downside to this is if the IP address of the Windows server changes, then it will not connect. But if this happens I guess I will use the same process to determine the new IP address and remount the server loaction.

I hope this helps anyone else who is getting Connection Failed errors when trying to connect to a shared Windows server on a Windows network.