HomeTechOps

Mac

Mac can't see NAS or printer after Tahoe update

Why your Mac stopped seeing the NAS, shared folders, or printer after updating to macOS Tahoe (macOS 26) — the Local Network privacy permission that resets on update, Bonjour/mDNS discovery, and the VPN that hides the LAN.

The Local Network permission list

Reference images and diagrams. Click any image to view full resolution.

macOS System Settings, Privacy and Security, Local Network, showing the per-app permission list with enabled toggles; the app names and icons are blurred for privacy.
Privacy & Security → Local Network: each app needs this toggle on to discover a NAS or printer, and a macOS update can silently reset it. App names blurred for privacy. First-party screenshot (macOS Tahoe 26.5).

Problem summary

I'm here because after updating to macOS Tahoe (macOS 26) my Mac can't see things on my own network anymore — the NAS or shared folders vanished from the Finder sidebar, my printer isn't found, or an app like Plex or a scanner utility can't discover local devices. The internet works fine. On modern macOS this is usually the Local Network privacy permission (which apps now need to find devices and which can reset across updates), plus Bonjour/mDNS discovery and the occasional VPN that's routing your local traffic away. This page walks each one and gives a reliable connect-by-address fallback.

Operator snapshotEvidence first
First proof

Open Privacy & Security → Local Network and check the app's toggle.

Screen to open

dns-sd -B _smb._tcp

Expected signal

The app that can't find devices is listed and ON.

Stop boundary

Disabling the firewall entirely instead of just the 'block all incoming' option.

Layer path

1Seeing a NAS or printer is a discovery problem, distinct from reaching it. Discovery uses Bonjour/mDNS to advertise services on the LAN; reachability is whether the Mac can actually open a connection to the device's IP. A device can be perfectly reachable yet invisible — which is why 'connect by IP' is both the diagnostic and the workaround.
2On modern macOS the decisive new layer is the Local Network privacy permission: an app must be explicitly granted Local Network access before it can send the mDNS queries that find devices, and that grant can reset or drop across a macOS update. So 'it worked before the update' usually means a permission, not the device, changed.
3Two environmental factors mask discovery: a full-tunnel VPN that routes LAN traffic away (device unreachable), and different subnets/VLANs where mDNS doesn't cross without a reflector (device reachable by IP but never discovered). Naming reachable-vs-discoverable and same-subnet-vs-not points straight at the fix.
Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

1

Grant the permission

Check: Privacy & Security → Local Network → toggle the failing app ON.

Expected result: The app can issue mDNS queries again.

If not: If the app isn't listed, relaunch it and trigger discovery to prompt.

2

Prove reachability

Check: Connect by IP with `smb://<NAS-IP>` and add the printer by IP.

Expected result: You confirm the device is reachable and get working access now.

If not: If IP fails, switch to the reachability branch (VPN/subnet/NAS).

3

Clear network blockers

Check: Disconnect a full-tunnel VPN; turn off firewall 'Block all incoming'.

Expected result: LAN traffic and discovery responses are no longer suppressed.

If not: If devices are cross-subnet, plan mDNS reflection or keep using IP.

4

Verify discovery system-wide

Check: Run `the "Browse for SMB file shares via Bonjour" command below` / `_ipp._tcp`.

Expected result: Devices appear, confirming mDNS works at the OS level.

If not: If they appear here but not in an app, that app still lacks the permission.

5

Re-test and settle

Check: Relaunch the app / reopen Finder's Network section.

Expected result: Devices are visible and connect without an IP.

If not: If discovery still fails, keep the connect-by-IP / manual-add path.

Decision tree

Decision tree

If: Connect-by-IP works but the app/Finder can't discover the device.

Then: A discovery-layer failure — usually the Local Network permission.

Action: Grant the app Local Network access; verify system mDNS with `dns-sd`.

If: Even connect-by-IP fails and a full-tunnel VPN is active.

Then: The VPN is routing LAN traffic away from the local network.

Action: Disconnect the VPN or enable local-LAN/split-tunnel access, then retry.

If: Connect-by-IP fails, no VPN, device on a different subnet/VLAN.

Then: mDNS can't cross subnets and routing may be blocked between VLANs.

Action: Use IP directly, and enable mDNS reflection/repeater on the router if cross-subnet discovery is needed.

If: `dns-sd` shows nothing and firewall 'Block all incoming' is on.

Then: The firewall is suppressing discovery responses.

Action: Turn off 'Block all incoming connections' (keep the firewall on otherwise) and retest.

If: No client (not just this Mac) can reach the NAS/printer.

Then: The device's service is off (SMB disabled, printer offline) — not a Mac problem.

Action: Fix the NAS share/printer service; confirm the device is healthy.

Evidence

Evidence table

SymptomEvidence to collectLikely layerNext action
NAS/printer vanished right after the Tahoe update.Privacy & Security → Local Network shows the app off/missing.Local Network permission reset by the update.Toggle the app on; relaunch to re-trigger the prompt if absent.
App can't discover, but `smb://<IP>` connects.Connect-by-IP succeeds; `dns-sd` works system-wide.Discovery layer (app permission), device fine.Grant Local Network access to the app.
Nothing local is reachable while VPN is on.Disconnecting the VPN restores access.Full-tunnel VPN routing LAN traffic away.Enable local-LAN access / split-tunnel, or disconnect.
Device on guest/IoT VLAN never appears.Same device reachable by IP from the Mac's subnet only via routing.Cross-subnet mDNS not reflected.Connect by IP; enable mDNS reflection on the router.
`dns-sd` lists nothing for any service.Firewall 'Block all incoming connections' is enabled.Firewall suppressing discovery.Disable that single option; keep the firewall on.
Reference

Commands and settings paths

Browse for SMB file shares via Bonjour

dns-sd -B _smb._tcp

Where: Terminal on the Mac (Ctrl-C to stop).

Expected: Lists NAS/file-share services as they're discovered on the LAN.

Failure means: Nothing appears means mDNS is blocked or devices are on another subnet.

Safe next step: If system mDNS works, grant the failing app Local Network access.

Browse for network printers via Bonjour

dns-sd -B _ipp._tcp

Where: Terminal on the Mac (Ctrl-C to stop).

Expected: Lists AirPrint/IPP printers as they advertise themselves.

Failure means: Empty list means the printer isn't advertising or mDNS is blocked.

Safe next step: Add the printer by IP as a robust fallback.

Connect to the NAS by address (discovery bypass)

Finder → Go → Connect to Server → smb://<NAS-IP>

Where: Finder on the Mac.

Expected: Mounts the share directly, proving reachability independent of discovery.

Failure means: If this fails too, it's reachability (VPN/subnet/NAS service), not discovery.

Safe next step: Fix the VPN/subnet/NAS; if it works, fix the discovery layer separately.

Resolve a specific advertised service

dns-sd -L <ServiceName> _smb._tcp local

Where: Terminal on the Mac, using a name from the browse list.

Expected: Shows the host and port behind a discovered service.

Failure means: If it can't resolve, the advertisement is incomplete or stale.

Safe next step: Connect by IP and check the device's service configuration.

Hardware boundary

Hardware and platform boundary

Change only when

  • Enable mDNS reflection (Avahi reflector or your router/UniFi's mDNS option) if you deliberately keep NAS/printers on a separate VLAN and want cross-subnet discovery.
  • Set static IPs or DHCP reservations for the NAS and printer so the connect-by-IP fallback stays stable and you don't depend on discovery.

Evidence that matters

  • A router that supports mDNS reflection/repeater across VLANs if you segment your network.
  • Stable device addressing (reservations) so manual connect-by-IP is reliable.
  • Devices that correctly advertise their services (SMB, AirPrint/IPP) on the same subnet as the Mac.

Evidence that does not matter

  • Reinstalling printer drivers — a permission reset isn't fixed by drivers.
  • The Mac's Wi-Fi generation — discovery is a permission/mDNS issue, not bandwidth.
  • Factory-resetting the NAS before checking the Local Network permission.

Avoid

  • Disabling the firewall entirely instead of just the 'block all incoming' option.
  • Leaving a full-tunnel VPN on and concluding the device is broken.
  • Relying on Bonjour discovery across VLANs without a reflector — use IP instead.

Related tool/checklist

Use the linked tool when you need a guided plan from your exact symptoms instead of a static checklist.

NAS setup planner

Related problems

Last reviewed

2026-06-02 · Reviewed by HomeTechOps. Reviewed against Apple's Local Network privacy and network guidance; separates discovery (Bonjour/mDNS + the Local Network permission that resets across updates) from reachability (VPN, subnet/VLAN, device service), and uses connect-by-IP as both the diagnostic split and the immediate workaround.

Sources/assumptions

  • Assumes a Mac on macOS Tahoe (macOS 26) that lost local-device discovery after updating; the Local Network privacy permission applies to recent macOS and can reset across updates.
  • Discovery uses Bonjour/mDNS; cross-subnet/VLAN discovery requires mDNS reflection on the network, which is outside the Mac's control.
  • Commands (`dns-sd`, Connect to Server) follow Apple's documented behaviour; NAS/printer menu labels vary by vendor.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.