Posted on 09-28-2017 06:53 PM
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?
Solved! Go to Solution.
Posted on 08-03-2018 07:21 AM
These should help.
Posted on 09-28-2017 07:29 PM
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'
Posted on 09-28-2017 09:51 PM
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 'Server1.this.org'? 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?
Posted on 09-28-2017 10:44 PM
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://naunsw005.aus01.bnkinet.com/g_sy$ (where naunsw005.aus01.bnkinet.com 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://firstname.lastname@example.org/g_sy$ would have worked for macOS Sierra 10.12.6
Posted on 09-29-2017 06:11 AM
We've battled this, been frustrated over this and finally started telling people experiencing it to connect to shares using
cifs://share.name. That has helped, albeit the connection is much slower.
Give that a whirl if you can.
Posted on 09-29-2017 07:49 AM
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.
Posted on 09-29-2017 10:51 AM
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 ?
Posted on 10-02-2017 03:48 PM
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.
Posted on 10-02-2017 08:50 PM
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 :)
Posted on 10-03-2017 01:20 PM
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?
Posted on 10-27-2017 11:30 AM
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
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" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<dict> <key>RunAtLoad</key> <true/> <key>Label</key> <string>com.plist.name</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/com.plist.name.plist
sudo chown root /Library/LaunchAgents/com.plist.name.plist
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
Posted on 11-13-2017 04:45 AM
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.
Posted on 07-02-2018 07:40 AM
This stack helped my issue with SMB: https://apple.stackexchange.com/questions/257836/mac-mini-cant-connect-to-my-corporate-smb-server-was-working-some-days-ago
Turns out an Android kext was causing issues.
Posted on 08-03-2018 07:21 AM
These should help.
Posted on 10-23-2018 11:22 PM
sudo defaults write /Library/Preferences/com.apple.NetworkAuthorization AllowUnknownServers -bool YES
worked for us.
It came from https://support.apple.com/en-us/HT207112