Windows Server network shares on the Mac: connect securely and fix problems

For a lot of offices, the department share on the file server is still where the real work lives. On Windows it’s an S: drive that’s simply there when you log in. On the Mac it works differently, and almost every admin runs into that in the first week. In this part of the series Mac and the rest of the world we look at how to connect a Mac cleanly and securely to a shared folder on Windows Server over SMB. First the everyday route through the Finder, then what the Mac already does by default, which settings you do and don’t need to change, and how to fix the usual problems. At the end there’s a reference section with Terminal commands for admins.

What’s different from Windows

A few differences up front, so the rest makes more sense:

• No drive letters. A share shows up on the Mac as a volume in the Finder, under Locations and in the /Volumes folder. There’s no fixed S:. You can put the share in the Finder sidebar or the Dock, which makes it just as easy to find.
• Addresses as URLs. Where you’d type \\fileserver\Department on Windows, on the Mac you use smb://fileserver.company.com/Department. Forward slashes, with smb:// in front.
• No logon script. There’s no Group Policy that maps drives when you log in. You handle that with login items, the keychain or your MDM.
• Same language. The Mac speaks SMB 2 and SMB 3, with signing, encryption and Multichannel. There’s no translation layer needed, it’s mostly a matter of setting things up properly.

Connecting through the Finder

For most users, this is all they need:

1. In the Finder, choose Go > Connect to Server, or press Command-K.
2. Type the address, for example smb://fileserver.company.com/Department, and click Connect.
3. Choose Registered User and enter your user name and password. In a domain, COMPANY\jansen or jansen@company.com both work.
4. Only save the password in your keychain on a Mac that’s yours and properly secured.

Two handy extras. The Connect to Server window has a + button that saves the address as a favourite. And if you want the share to come back by itself after you log in, open System Settings > General > Login Items & Extensions and drag the mounted share into the Open at Login list. With a saved password or a Kerberos ticket, that happens without any prompts.

Leave out the share name, so just smb://fileserver.company.com, and you get a list of every share you have access to, so you can pick one or more.

Use the server name, not the IP address

It sounds like a detail, but this is the most important rule in this whole piece. Always connect using the server’s full DNS name, for example fileserver.company.com, not 192.168.1.20.

The reason is Kerberos. In an Active Directory environment, Kerberos is the secure and pleasant way to sign in: no password going over the wire and no prompts if you’re already signed in. Kerberos works with the server’s name. Connect by IP address and the connection usually falls back to NTLMv2. That works, but it’s weaker and you get more password prompts. If connecting by IP works and by name doesn’t, you have a DNS problem. Fix that rather than switching to the IP address.

Watch out for .local

Is your Windows domain still called something like company.local? Then you can run into odd problems on the Mac. The Mac uses .local for Bonjour, the technology devices use to find each other on the network. Names ending in .local get looked up through Bonjour first instead of your DNS server. The result: slow or failed connections, especially over VPN. Apple advises against .local for new networks for exactly this reason. If you can’t rename the domain any time soon, add your domain as a search domain in the Mac’s network settings and test carefully, including over VPN. For a new domain, use a subdomain of a domain you own, such as ad.company.com.

Signing in without a password: Kerberos

The Mac no longer needs to be bound to the domain to use Kerberos. We advise against that old binding approach, see also A Mac in a Windows company network. The modern route goes through your MDM:

• Apple’s Kerberos SSO extension. A configuration profile that lets the Mac get a Kerberos ticket for your domain. After that, shares mount without a password prompt.
• Platform SSO with Microsoft Entra ID. If you use Intune and Platform SSO, Entra ID can also hand out Kerberos tickets for your on-premises Active Directory after sign-in. Microsoft calls this TGT mapping. Next to the Platform SSO profile you deploy a Kerberos SSO profile for your AD realm.

For Kerberos to work, a few things need to be right: the Mac uses the domain’s DNS servers (or reaches them over VPN), you connect by server name, and the clocks on the Mac and the domain controller match. A few minutes of difference is enough to make Kerberos fail. Run klist in Terminal to see whether you have a valid ticket.

What the Mac already does by default

There are long nsmb.conf files floating around the internet that you supposedly “have to” install. Many of those settings are already right by default, and some of those lists even switch security off. This is what the Mac does without any changes, according to its own manual (man nsmb.conf) and Apple’s support pages:

So in a modern Windows environment, the only things you really want to change are old SMB 1 and the NetBIOS fallback. Apple describes this itself in How to disable SMB 1 or NetBIOS in macOS.

The recommended nsmb.conf

The Mac’s SMB settings live in the file /etc/nsmb.conf. It doesn’t exist by default. For most offices, this is enough:

[default]
protocol_vers_map=6
port445=no_netbios

protocol_vers_map=6 enables only SMB 2 and SMB 3 (2 for SMB 2 plus 4 for SMB 3). port445=no_netbios makes the Mac connect over port 445 without falling back to NetBIOS. You’ll see minauth=ntlmv2 in a lot of guides too. It does no harm, but it’s already the default.

To put the file on a single Mac:

sudo test -f /etc/nsmb.conf && sudo cp -p /etc/nsmb.conf /etc/nsmb.conf.backup
sudo nano /etc/nsmb.conf

If there’s already a [default] section, add the lines there. Don’t create a second one. After saving, disconnect all shares and connect again, because the settings only apply to new connections. To undo it, restore the backup, or delete the file if it wasn’t there before. Apple itself says that’s safe.

Two things worth knowing. There’s also a per-user file, ~/Library/Preferences/nsmb.conf, but the global file in /etc wins when they conflict. And next to [default] you can create sections per server. That way you could allow SMB 1 for one old NAS while the rest of the network can’t use it anymore. The exact layout is in man nsmb.conf.

For more than a few Macs: there’s no standard configuration profile setting for nsmb.conf. In Intune or another MDM you deploy it with a small shell script that creates the file. Make sure the script doesn’t blindly overwrite an existing file.

Enforcing signing and encryption

Signing and encryption aren’t the same thing. Signing proves a message really comes from the server or the Mac and wasn’t changed along the way. That protects against relay attacks. Encryption also scrambles the contents, so nobody on the network can read your files.

Our advice is to handle both on the server side. Note: Windows Server 2025 requires signing by default for its own outgoing connections, but not for Macs and PCs connecting to it. You switch that on yourself, with the Group Policy setting Microsoft network server: Digitally sign communications (always) or with Set-SmbServerConfiguration -RequireSecuritySignature $true. If you share files from a PC running Windows 11 24H2, signing is already on by default there. On Windows Server you turn encryption on per share, for example with Set-SmbShare -Name Department -EncryptData $true. The Mac simply goes along. If you also want to enforce it from the Mac, for laptops that end up on unknown networks for example, you can:

[default]
protocol_vers_map=6
port445=no_netbios
signing_required=yes
force_sess_encrypt=yes

Test this on a few Macs first. If a server or NAS doesn’t support encryption, connecting with this setting will fail. Signing and encryption cost some speed, but with a modern Mac and server you’ll barely notice on a normal office network.

Checking that it’s right

smbutil shows you exactly how a connection was set up:

smbutil statshares -a
smbutil multichannel -a

statshares shows, per share, the SMB version and whether signing and encryption are active, among other things. If you see SMB_3.1.1 and signing on, you’re good. multichannel shows which network connections are being used. Since macOS 15 the Mac can open several channels per network card if the hardware supports it, which makes a real difference at 10 gigabit.

Fixing problems

The server can’t be found

First check that the name resolves with dig +short fileserver.company.com, and that port 445 is reachable with nc -vz fileserver.company.com 445. A failed ping doesn’t tell you much, plenty of firewalls block it. If port 445 doesn’t work, look at the VPN, the Windows Firewall and any firewall between network segments. scutil --dns shows which DNS servers the Mac is using. Outside the office, those should be the domain’s DNS servers through the VPN.

You end up signed in with the wrong account

The Mac reuses an existing session to the same server. If you were connected with another account before, that account sticks. Disconnect every share on that server and connect again. mount | grep smbfs shows what’s still mounted.

Reading works, writing doesn’t

On Windows Server, the effective permissions are the combination of the share permissions and the NTFS permissions. The stricter one wins. So check both, plus the groups the user belongs to. The Mac itself is rarely the cause here.

The Finder shows old contents

With SMB 2 and 3 the Mac remembers folder contents for a short while. If the contents on the server change very often, or you sometimes see only part of the files, you can switch that cache off with dir_cache_max_cnt=0 in the [default] section. That’s in Apple’s own article too. It does slow down large folders, so only do it if you need to.

Browsing large folders is slow

Start by switching off .DS_Store files on network shares. The Finder creates them in every folder you open, which slows down browsing and leaves clutter for Windows colleagues. Apple documents this itself:

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool true

Then log out and back in. If you use both Wi-Fi and a cable, add mc_prefer_wired=yes to nsmb.conf so Multichannel prefers the cable. Only switch Multichannel off completely with mc_on=no if you really have a compatibility problem.

Strange characters in file names

Characters the Mac allows but Windows doesn’t, such as a colon or a question mark, turn into odd names on the share. We wrote a separate piece on that: Zip, rar and file names between Mac and Windows. For the hidden ._ files your colleagues sometimes see, read Hidden Mac files on USB sticks.

Need more information

You can watch a connection attempt live in Terminal with:

log stream --info --predicate 'process == "mount_smbfs" OR process == "NetAuthSysAgent" OR subsystem CONTAINS[c] "smb"'

Stop with Control-C. Don’t paste those log lines on a public forum, they contain user names and internal server names.

Which approach fits you?

A few Macs, no management

Connect through the Finder using the server name, password in the keychain, share in the login items. Put the short nsmb.conf with just SMB 2 and 3 and no NetBIOS on every Mac.

Macs in Intune with Entra ID

Platform SSO with a Kerberos SSO profile for your AD realm, so users reach the shares without password prompts. nsmb.conf and the .DS_Store setting through a script from Intune. Signing and encryption are handled on the server.

Sensitive data or lots of remote workers

Encryption required on the shares that matter, signing required on the server, and optionally enforced from the Mac as well. Access only through VPN, and check with smbutil statshares that encryption really is on.

Reference: Terminal commands

For admins who’d rather type than click. Replace the server, share and user with your own. The password is always asked for properly. Never put it in the command or the URL, or it ends up in your shell history.

# Test name and port
dig +short fileserver.company.com
nc -vz fileserver.company.com 445

# List available shares (domain account)
smbutil view '//COMPANY;jansen@fileserver.company.com'

# Mount through the Finder dialog
open 'smb://fileserver.company.com/Department'

# Or mount in your own location, no admin rights needed
mkdir -p "$HOME/Shares/Department"
mount_smbfs '//COMPANY;jansen@fileserver.company.com/Department' "$HOME/Shares/Department"

# Spaces in a share name become %20
mount_smbfs '//COMPANY;jansen@fileserver.company.com/Team%20Files' "$HOME/Shares/Team"

# Check the connection
smbutil statshares -a
klist

# Unmount cleanly, and see what still has files open
diskutil unmount "$HOME/Shares/Department"
lsof +D "$HOME/Shares/Department"

Only use diskutil unmount force when there’s really no other way. Anything not yet saved will be lost.

Step-by-step plan

1. On the Windows side, check that SMB 1 is off, port 445 is open and the share and NTFS permissions are right.
2. Make sure the server has a proper DNS name the Macs can resolve, over VPN too. Check whether your domain ends in .local.
3. Deploy the short nsmb.conf to the Macs: SMB 2 and 3 only, no NetBIOS.
4. Set up Kerberos through the Kerberos SSO extension or Platform SSO, so users don’t keep typing their password.
5. Turn on signing, and encryption where needed, on the server.
6. Switch off .DS_Store on network shares.
7. Have users connect with Command-K using the server name, and add the share to their login items.
8. Check version, signing and encryption on a few Macs with smbutil statshares -a.

And with Apple?

Apple doesn’t make servers anymore. macOS Server was discontinued in 2022, and while a Mac can share folders over SMB itself, that’s meant for small setups, not as a department server. If you stay fully within Apple, files in practice go to iCloud Drive or to a NAS that speaks SMB. For a business on Microsoft 365, SharePoint and OneDrive make more sense than a classic file server. The good news is that the Mac and Windows Server work together fine over SMB. Most things go wrong in DNS, Kerberos and permissions, not on the Mac itself.

This whitepaper describes the situation in October 2026 with macOS Golden Gate (macOS 27) and Windows Server 2022 and 2025. The default values come from man nsmb.conf and Apple’s support articles. Check them on your own Mac with man nsmb.conf before rolling anything out widely.

Need help setting this up for your organisation? Email frank@analystict.nl.

This article is part of the Mac and the rest of the world series, where you’ll find every part in one place.