macOS High Sierra 10.13.0 - smb mount drive issue

Contributor III

Hi all,

This issue is based on another discussion topic

I have now upgraded our test Macbook to macOS High Sierra 10.13.0. But now any smb mount drives do not work. Since the days of macOS Sierra 10.12.x, we have been telling our users to use
smb://<domain><username>@<server name>/<drive name>

But now even that does not work for High Sierra.

Anyone have this working?



These should help.

View solution in original post




I just generally put the servername/share and that's it.
It seems to add the smb part in there itself.
That's if you're using command+k or Go>'connect to server'

New Contributor

Hi Bernard,

Can you confirm for me, when you say you map to smb://<domain><username>@<server name>/<drive name>

the <server name> part is it just the domain name of the server 'Server1' or is it the fully qualified domain name ''? I had to use the FQDN for my mounting script to work. Also my mounting script does not specify the domainusername component. mine looks something like this:


Does this help?

Contributor III


The network drive I'm trying to connect to is (only an example)
aunsw005g_sy$ That is what I would map to if I'm using a Windows machine.

So on my Mac, I tried the following
smb://$ (where is the fully qualified domain name. I can ping this from my Macbook)

All of them don't work for High Sierra 10.13.0

The last attempt
smb://$ would have worked for macOS Sierra 10.12.6

Contributor III

We've battled this, been frustrated over this and finally started telling people experiencing it to connect to shares using cifs:// That has helped, albeit the connection is much slower. Give that a whirl if you can.

New Contributor II

We use the Login Items payload to mount smb drive mount shares for our school district. Our JAMF rep confirmed that the Login Items payload does not function as expected in macOS High Sierra. You may not being using that, but just an FYI.

New Contributor III

With properly configured DHCP, i've had no issues on 10.13 mounting SMB shares via smb://share/path/to/folder. On 10.12.5 however we were operating with smb://<username>@fqdn.of.share/path/to/folder though. Give that a shot @Bernard.Huang ?

Contributor III

Hi guys,

Thanks for all the feedback so far. But I still haven't had any luck connecting to remote drives via smb or cifs.

I even tried using IP address, so it no longer depend on DHCP to resolve the addresses, but still won't connect. I wonder what changed between 10.11.6 > 10.12.5 > 10.13.0 :( For El Capitan, remote network drive works all day everyday.

Contributor III

Hi all,

Did further testing. When I uninstalled McAfee EPM, I can now connect with network drives. So, it was McAfee causing all the fuss.

Thanks for all the replies :)

New Contributor

Manually mounting a ReadyNAS unit works like a charm but can't use the old login items drag/drop to mount these for our users. Anyone know a scripting solution to get the SMB shares to mount upon login?

New Contributor

You can use a script and a plist to get a mount at login solution. I am doing a mount for all users that login into a shared domain connected computer in the following fashion:

First write a script like:
mount volume "smb://domain/server/share name"

I also added this so that mounted drive will show on the desktop of ease of use for users:
tell application "Finder" activate open window of Finder preferences set desktop shows connected servers of Finder preferences to true close window of Finder preferences
end tell

Then create a .plist file like this and place in /Library/LaunchAgents:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">
<dict> <key>RunAtLoad</key> <true/> <key>Label</key> <string></string> <key>ProgramArguments</key> <array> <string>osascript</string> <string>/scriptpath/scriptname.scpt</string> </array>

After saving the plist and the scpt run this in the terminal:

sudo chmod 600 /Library/LaunchAgents/
sudo chown root /Library/LaunchAgents/

when using a domain connected computer your username and password will usually path through, but not always. Have them enter username and password and save to minimize user interaction

I think just changing the plist location to the user's launchagents location would let you do this user specific

New Contributor

On 10.13, We have seen this issue mounting home drives on smb's shares that are hidden ($ at the end). AD users that have never signed in before fail to sign in at all. We you are using "create mobile account" and haven't tested it without this checked. But moving a user's home drive to a non-hidden share and they can sign in just fine. Hope a fix/workaround is available soon.

New Contributor

This stack helped my issue with SMB:

Turns out an Android kext was causing issues.


These should help.

Contributor III

The command

sudo defaults write /Library/Preferences/ AllowUnknownServers -bool YES

worked for us.

It came from