Fix Revit Central File Path Issues: Mapped Drives vs UNC

If you’re seeing the “Central Model is not available” error in Autodesk Revit, you are almost always dealing with a path inconsistency between mapped drives and UNC paths.

This issue shows up in multi-office environments, VPN setups, and even inside a single office where drive mappings are not standardized. It breaks worksharing, blocks Create New Local, and causes Revit Links to go missing.

This guide explains exactly what is happening, why it started, and how to fix it without guesswork.

What Changed in Revit (Why This Problem Exists)

For years, Revit automatically converted mapped drive paths like:

P:\Projects\ProjectA.rvt

into their UNC equivalent:

\\Server01\Projects\ProjectA.rvt

Starting with Revit 2015, that behavior changed.

Revit now stores the exact path used when the central model is created. If that path is a mapped drive, it becomes part of the model’s identity.

That means:

  • Revit no longer resolves paths automatically
  • The drive letter becomes hardcoded
  • Any mismatch breaks collaboration

The Core Problem: Path Inconsistency

The issue appears when different users access the same file using different path definitions.

Typical scenario:

  • Office A maps the server to R:
  • Office B uses Z: or accesses via \\ServerName\...

Even if both paths point to the same physical location, Revit treats them as different.

Result:

  • Create New Local is grayed out
  • Users cannot join the central model
  • Worksharing fails silently or inconsistently

Before 2015, Revit normalized this automatically. Now it does not.

Mapped Drives vs UNC Paths (What Actually Matters)

Mapped Drive

R:\Projects\ProjectA.rvt
  • Depends on local machine configuration
  • Not consistent across users
  • Breaks in multi-site environments

UNC Path

\\Server01\Projects\ProjectA.rvt
  • Direct network reference
  • Independent of user setup
  • Required for stable Revit worksharing

Rule: If the central model is not created using a UNC path, expect problems.

How to Fix Revit Path Issues (Step-by-Step)

Method 1 — Browse via Network (Recommended)

When creating the central model:

  • Do not select P:\ or Z:\
  • Navigate through:
    • Network
    • Server name
    • Shared folder

This ensures Revit records a UNC path from the start

Method 2 — Manual UNC Path Entry

In Save As or Synchronize with Central:

  • Type the full path manually:
\\ServerName\ShareName\Folder\
  • Press Enter before saving

This forces Revit to register the correct path.

Method 3 — Reset the Central Model Path

If the model is already broken:

  1. Open the model
  2. Go to:
    • Synchronize with Central
    • Modify Settings
  3. Click Browse next to central model location
  4. Re-select the file using the UNC path

This can re-align the model without rebuilding it.

Why This Still Matters (Even Today)

Even if your company uses Autodesk BIM Collaborate Pro, many projects still run on:

  • Local servers
  • Secured networks
  • Infrastructure environments

In those setups:

  • UNC paths are mandatory
  • Mapped drives are a risk factor

This also affects:

  • Revit Links
  • Dynamo scripts
  • Batch automation tools
  • BIM Manager workflows across multiple machines

Best Practices for BIM Teams

If you want this problem to disappear across projects:

  • Always create central models using UNC paths
  • Never rely on mapped drives for shared models
  • Standardize access paths across offices
  • Use Relative paths for Revit Links when possible
  • Avoid mixing:
    • mapped drives
    • UNC paths
    • IP-based paths
  • Document your path strategy in BIM Execution Plans (BEP)

Cloud vs Local: When This Problem Goes Away

Using cloud worksharing (via Autodesk):

  • Removes dependency on network paths
  • Eliminates mapped drive inconsistencies
  • Central model is hosted and accessed uniformly

However:

  • Not always allowed (security, infrastructure, cost)
  • Hybrid environments still face this issue

So this problem is still very relevant.

Real-World Failure Pattern

Typical failure case:

  • Project created using P:\Projects\...
  • Another office accesses via \\Server\Projects\...
  • Revit sees two different paths
  • Links show as Not Found
  • Users cannot create locals

No warning. Just broken workflow.

FAQ: Troubleshooting Revit Network Paths

Why is “Create New Local” grayed out?

Because the path stored in the model does not match your system.

Example:

  • Model expects: P:\Project.rvt
  • Your machine sees: Z:\Project.rvt

Revit requires an exact match, not a logical one.

Does using an IP address instead of server name help?

You can use:

\\192.168.1.50\Projects\

But this is not recommended.

If the IP changes:

  • All links break
  • All models lose reference

Use server names, not IPs.

How do I check the current central model path?

Go to:

  • Collaborate tab
  • Synchronize with Central
  • Synchronize and Modify Settings

Check Central Model Location

This shows exactly what Revit is using:

  • mapped drive
  • or UNC path

Does this affect Revit Links?

Yes.

If a link is loaded using a mapped drive:

  • Users without that drive letter will see Not Found

Best approach:

  • Use Relative paths when possible
  • Otherwise use UNC paths

What if we use DFS (Distributed File System)?

DFS paths like:

\\Company\Projects\

can simplify access.

But watch for:

  • latency
  • synchronization delays
  • .slog heartbeat issues

All users must hit the same namespace consistently

Can this be fixed without recreating the central model?

Sometimes yes.

Using the Sync reset method can fix path alignment.

If not:

  • Detach from central
  • Recreate central model using UNC
  • Relink everything properly

Final Takeaway

This is not a Revit bug. It is a path consistency problem.

If your team mixes:

  • mapped drives
  • UNC paths

you will get:

  • broken links
  • blocked worksharing
  • lost time

The fix is simple but strict:

Always use UNC paths when creating and managing central models.

Similar Posts