There seem to be different problems and solutions to this problem floating around:

  1. Fix switching from SMB to cifs
  2. Not being able to access OS X shares from Windows
  3. All kinds of problems with SMB and Mavericks over at Apple

My problem is like in the first link: I have a Raspberry Pi (Linux) SMB server. It serves files to my MBP running Mavericks. However, I cannot connect to the Pi. The Console logging says:

30.10.13 21:50:53,422 NetAuthSysAgent[6632]: smb_mount: mount failed to raspberrypi/MyShare, syserr = File exists

When I go to /Volumes in a shell and do an ls, I get this:

user@mac:/Volumes $ ls -l
ls: MyShare: Invalid argument
total 8
lrwxr-xr-x  1 root  admin  1 28 Okt 21:39 M4 -> /
user@mac:/Volumes $ 

So my main hard drive M4 is visible, the share produces an invalid argument. I already rebooted my Mac three times.

How can I solve this?

  • Out of interest, is there a reason you are using SMB over AFP on your RPi?
    – grg
    Oct 30 '13 at 22:29
  • Yes, I also have Windows machines on my network. :)
    – Arne
    Oct 31 '13 at 8:06
  • Would you consider using SMB on Windows and AFP on Mac? :)
    – grg
    Oct 31 '13 at 11:24
  • Oh well... Maybe I'll try it, just because I never used AFP! However, after the fourth reboot everything works -- for now! I'll keep an eye on this problem, and will try to formulate a useful answer.
    – Arne
    Oct 31 '13 at 14:00
  • 1
    Done! :) I've added some more information about setting up Netatalk in case anyone else finds this question.
    – grg
    Nov 1 '13 at 10:38

If you can't get SMB working, try AFP. You can run both side-by-side, and use SMB on your Windows and AFP on OS X.

To set up AFP on your Raspberry Pi, you can use the following command:

sudo apt-get install netatalk

This will install Netatalk on your RPi, and following successful installation, the RPi should automatically show in the Shared section in Finder and the Network neighbourhood (⌘⇧K):

If not, you can connect manually by pressing ⌘K and typing afp:// followed by the IP address of your RPi.

  • After a month of usage, I can say this works fine. But it seems actually best to name the AFP server differently than the SMB server. I changed the netbios name in smb.conf, but you could also change the name in netatalk's afp_signature.conf.
    – Arne
    Dec 3 '13 at 20:19

This post solved my problem. Try manually setting the maximum transmission unit under your system settings>Networks>WLAN/Ethernet>Advanced>Hardware>Custom MTU of 1320.

My Problem was also a mounting delay problem. Once I got things mounted, everything worked normally. Apparently, the default MTU is too high. Manually lowering this made mounting smb shares a much faster process.

The original post I will paste here for the sake of keeping stackexchange self-contained:

I have embarked on a testing mission... Using Wireshark I managed to see that packets were being dropped when transferring over the network - the same patterns didn't exist with the same transfer over wireless or the same transfer wired to a Windows server.

So I Googled a little and came up with the following command:

ping -c 1 -D -s 1500 smbserver

It basically pings the server with an MTU of 1500, to which I got:

ping: sendto: Message too long

Note that I also get this error on a Windows server - but what may be the issue is that when your software gets this response it is supposed to automatically decrease the MTU until it finds the optimal one for transfer of packets - something that Mavericks appears to be doing with Windows servers but not with Linux ones.

So using the ping command I can find an optimal MTU for transfer:

ping -c 1 -D -s 1320 smbserver

Now I get the answer:

round-trip min/avg/max/stddev = 0.829/0.829/0.829/0.000 ms

I had to mess around trying to find the optimal level but it gives you an idea on the test. After this I take my number and go to:

System Preferences -> Network -> USB Ethernet -> Advanced... -> Hardware -> Configure: Manually -> MTU Custom: 1320

After this, I disconnected my shares, re-established them and then tried another transfer up to my Linux server. Success! Granted it's not what I'd deem to be full speed, but to get a 5GB transfer down from 8 hours to 30 minutes seems better. It has taken it from completely unusable to tolerable.

I'm not entirely sure what the root of the problem is as I'm not a networking expert, as the stepping back of MTU appears to work on a Windows server and not a Linux one, and it worked fine in previous versions of OS X, my guess is that it is driver and/or stack related.

BTW I tried updating to 10.9.1 via the Developer download before trying this, the 10.9.1 upgrade didn't fix the issue for me before I went troubleshooting.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .