Hi,
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'
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 '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:
smb://<username>:@Server1.this.org/shared
Does this help?
Hi,
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)
smb://bernard@naunsw005.aus01.bnkinet.com/g_sy$
smb://ausernard@naunsw005.aus01.bnkinet.com/g_sy$
All of them don't work for High Sierra 10.13.0
The last attempt
smb://ausernard@naunsw005.aus01.bnkinet.com/g_sy$
would have worked for macOS Sierra 10.12.6
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.
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.
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 ?
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.
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 :)
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?
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" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<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>
</dict>
</plist>
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
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.
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.
These should help.
https://superuser.com/questions/1277259/smb-fileshare-mount-in-osx?noredirect=1&lq=1
https://superuser.com/questions/1269386/why-cant-i-mount-shares-by-smb-since-high-sierra?noredirect=1&lq=1
https://support.apple.com/en-us/HT207112
https://itunes.apple.com/gb/app/automounter/id1160435653?mt=12
https://forums.plex.tv/t/how-to-fix-auto-mounting-shares-broken-in-sierra-macos/162501
The command
sudo defaults write /Library/Preferences/com.apple.NetworkAuthorization AllowUnknownServers -bool YES
worked for us.
It came from
https://support.apple.com/en-us/HT207112