Why is a file in use by another user in CAD?

When a shared CAD project reports that a file is in use by another user, deleting the first temporary file you find is the wrong response. You first need to identify where the restriction originated: on the file server, inside the CAD application, or in its collaboration mechanism. Each layer identifies a different owner and calls for a different action.

The most dangerous habit in this situation is to force all server sessions closed and immediately reopen the drawing. That sometimes releases the file, but it can also discard changes that the workstation has not yet written. Reliable diagnosis starts with the exact path and the live owner, then moves to the application. A forced close remains the final controlled action.

The error indicates an access conflict, not a person

A message about another user usually means that the requested open mode conflicts with existing access. The application asks the operating system for read, write, delete, or a combination of those rights, while also declaring which actions other clients may take. If an active handle does not permit the new request, the server returns a sharing conflict. The CAD application reduces that response to a message that is easy to understand but not always precise.

A user may indeed own the conflicting handle. A service on that computer, a preview handler, backup software, antivirus software, an indexer, or an export process can also open the file. The account shown in the open-file list tells you whose identity the server accepted for the request. It does not prove that the person is editing the model or even has it visible on screen.

Do not confuse an ordinary SMB sharing restriction with an opportunistic lock, commonly called an oplock, or an SMB lease. Microsoft describes oplocks and leases as client caching mechanisms that reduce network round trips and coordinate caches when access conflicts. They affect when a client flushes changes and how it reacts to a new request, but an 'in use' message alone does not prove that an oplock is broken.

Two more independent layers exist. A temporary CAD support file may store the author name or operation state. A collaboration system may assign an object, workset, model, or transaction to an application user. The same symptom therefore requires three separate questions:

• Does the file server see a live handle for the required file?
• Does the CAD application or a support file identify an owner?
• Does the project have its own element, model, or transaction ownership?

If you do not separate those answers, an administrator may terminate an SMB session while the restriction remains in the central model, or delete a support file while a live client can still write through the server.

Identify what actually denied the write first

Start diagnosis with the exact UNC path, the operation, and the time of the error. The name Plan.dwg is useless when the archive, working folder, and delivery directory contain three files with that name. Record a path such as \\filesrv\cad-projects\Building-A\Plans\План.dwg, the CAD application and version, the user's command (open, save, rename, or publish), the time to at least the nearest minute, and the workstation name.

Ask the user not to terminate anything through Task Manager. If the likely owner is available, that person should return to the application, save local changes with the normal command, and close the document. Closing a window is not enough for a synchronized project: the user must first run the application's synchronization or relinquish borrowed objects. Then check whether the error has cleared for the second participant.

If the person says the file is closed, inspect the processes on that computer. A CAD application can leave a background process after its window disappears, while File Explorer can hold the file through the preview pane. Do not kill processes on a hunch. Match the path, account, and time, then ask the user to close the Explorer window, publishing queue, and application. Only treat the remaining handle as stale after a normal exit.

A useful non-writing check is to open the file read-only or copy it to a diagnostic folder. If reading works but saving or renaming fails, a sharing-mode conflict is likely. If reading also fails, check permissions, share availability, path length or validity, and the storage system itself. User-facing messages often combine different system errors, so a single operation does not replace evidence from the server.

Do not change permissions to release a lock. Permissions determine who may open a file, but they do not close a handle that has already been issued. Giving everyone Full Control adds the risk of deletion and ACL changes, while the existing conflict may remain until the client session ends.

Find the open handle on the file server

On Windows Server, the authoritative record for a remotely opened file is the SMB service on the node that serves the share. Get-SmbOpenFile returns the file and session identifiers, full and relative paths, client computer, and account. Run it in an elevated PowerShell session on the file server or through an approved administrative session.

Filter for one exact relative path first, not every file with a DWG extension:

$target = 'Building-A\Plans\План.dwg'
Get-SmbOpenFile |
  Where-Object ShareRelativePath -eq $target |
  Select-Object FileId, SessionId, ClientUserName,
                ClientComputerName, ShareRelativePath

The result has this shape:

FileId            : 4415226383589
SessionId         : 4415226380393
ClientUserName    : DOMAIN\user
ClientComputerName: 192.0.2.42
ShareRelativePath : Building-A\Plans\План.dwg

The values here are placeholders, while the fields mirror the command output. FileId lets you target a specific action. SessionId groups opens within one SMB session. ClientComputerName sometimes contains an address, so match it against the DHCP log, workstation management system, or service desk records. Do not assign ownership to the first employee who opened a similarly named file.

The same class of data is available in the Computer Management console under Shared Folders and Open Files. PowerShell is preferable because it preserves exact fields in the incident record and makes it harder to close the adjacent row with a mouse click. The older openfiles /query command also lists remotely opened files, but the object output from Get-SmbOpenFile is easier to filter on a current Windows Server without parsing text.

If the share sits on a cluster, a scale-out file server, or behind another access node, a query on a random server may return an empty list. Find the node that actually serves the share, and account for ScopeName and ClusterNodeName. For a NAS, use the manufacturer's open-file console. A check on the client computer can identify the local process, but it does not replace the handle state on the storage device.

An empty result is useful too. It means that this SMB server does not see a live open for the specified path. Verify the exact case and relative path, the actual destination server, and any DFS or cluster route, then move to support files and the CAD collaboration mechanism. Restarting the workstation before this check destroys part of the evidence.

Close a handle only after checking the work

A forced close is justified when the owner has confirmed a normal save and exit, the process is no longer running, and the server still shows the same FileId. Microsoft's Close-SmbOpenFile documentation gives an explicit warning: the command can cause data loss if the client has not flushed its changes to the server. That is not boilerplate. A CAD application may show a completed save while data remains in the client cache or in a temporary file-replacement sequence.

Before closing anything, record the main file's size and modification time, the presence of application-managed backups, and the Get-SmbOpenFile row. Ask the owner whether any local work remains unsaved, and stop colleagues from making new write attempts. For a central model, check the application's rules instead of copying only the main file.

Run a harmless preview of the command first:

Get-SmbOpenFile -FileId 4415226383589 |
  Close-SmbOpenFile -WhatIf

-WhatIf reports the intended action without closing anything. After the owner confirms, remove -WhatIf and keep the normal PowerShell confirmation prompt:

Get-SmbOpenFile -FileId 4415226383589 |
  Close-SmbOpenFile

Do not put -Force in the default operating note. The confirmation makes you look at the specific object once more. Pipelines that forcibly close every DWG are especially dangerous: they affect live drawings in other projects even though the incident involved one model.

Query the exact path again after the close. The owner should then start the application and check recovered or local data before a second person begins editing. Compare the modification time, open the model through the CAD application, and use its built-in integrity check if available. A successful open in File Explorer proves file accessibility, not project integrity.

Restarting an entire file service or server to clear one handle is almost always excessive. It breaks every user's opens, complicates recovery, and removes a useful view of the cause. A targeted close after coordination keeps the impact controlled.

DWL files identify an AutoCAD session but do not hold the DWG

In AutoCAD, DWL and DWL2 files help identify who opened a drawing, but they are not the lock itself. Autodesk's documentation for the WHOHAS command states that the temporary DWL stores the full path, login name, computer name, and opening date and time. The same documentation makes the distinction explicit: a DWL contains information and is not a lock file.

That distinction changes the order of work. If План.dwl and План.dwl2 sit next to План.dwg, use the application command to identify the user and computer. Then compare those values with ClientUserName and ClientComputerName on the server. A match gives you a sound reason to contact the owner. A mismatch shows that the metadata is stale, a different account opened the file, or you are inspecting the wrong path.

AutoCAD deletes the temporary files when a drawing closes normally. They may remain after a crash, although Autodesk says that they are overwritten the next time the DWG opens. The advice to delete every DWL and expect the problem to disappear is therefore wrong for two reasons. Deleting metadata does not close the SMB handle, and WHOHAS loses a useful diagnostic clue.

Delete a leftover DWL only after the server shows no live open, the application on the named workstation is closed, and the command and operating procedure for that product version permit cleanup. Before deletion, record its name, size, time, and, if needed, a copy for the incident record. Do not extend this rule to every extension beside a DWG: autosave, recovery, external-reference, and batch-publishing files perform different jobs.

For an ordinary DWG in current AutoCAD versions, the file system or access service enforces write sharing, not the DWL itself. This also explains odd behavior in some cloud-synchronized folders: a local copy can open independently and the conflict appears later during synchronization. Seeing a shared directory on screen does not mean the storage system provides the same guarantees as an approved SMB share.

A Revit element owner and an SMB client are different identities

In a workshared Revit model, release ownership through Revit before closing a server file. Autodesk describes three levels in server-based worksharing: element, model, and administrator locks. An element belongs to a Revit user, the model is locked temporarily during sensitive operations, and an administrator lock stops access for maintenance.

A Revit username does not have to match the SMB domain account. Autodesk also warns that if two people use the same Revit username, the server treats them as one user, which can cause data loss or model corruption. Unique application names are therefore part of the technical project setup, not merely good etiquette.

The normal path for a busy element is to ask the owner to synchronize with the central model and relinquish worksets and elements. Autodesk recommends that the original owner relinquish them because an administrator who assumes that identity can leave the local copy impossible to reconcile with the central model. If the employee is unavailable, the BIM coordinator must assess unsynchronized changes and follow the recovery procedure for that exact Revit version.

A model-level lock during synchronization normally releases automatically after a successful operation. If an operation was interrupted, retrying after a normal application restart is safer than manually deleting unknown files from the central model directory. The central file's backup folder stores editing-permission information and a worksharing log. Autodesk says not to delete or rename its contents arbitrarily.

The central file's SMB handle still provides evidence: it identifies the client and session accessing the storage. Forcibly closing it does not transfer element ownership to another engineer or confirm central-model integrity. After network intervention, the BIM coordinator checks the central model, and the affected user checks the local copy before synchronizing again.

A network interruption can leave an ordinary close hanging

Repeated locks often start at the workstation rather than the server: a laptop sleeps with a project open, a VPN drops, Wi-Fi switches access points, or a CAD process crashes. The server may continue to see a session or a reconnectable SMB handle after the user believes the application is closed. Waiting sometimes works, but a procedure with no measured limit turns waiting into guesswork.

Record four times for every case: the last successful save, the disappearance of the client process, discovery of the server handle, and the actual close. If the interval regularly matches sleep or a network switch, inspect power policy and connection quality. If locks remain after one CAD extension crashes, update and test that extension on its own instead of immediately changing SMB settings for the whole organization.

Antivirus and backup tools can also open large models, but excluding the entire CAD directory is risky. Prove ownership first through the server account, product security logs, and a reproducible test on a project copy. Then agree on a narrow exception with the security team and application vendor if one is genuinely required. An exception should not disable checks on every project file because of a rare conflict.

For an intermittent failure, gather data on both the client and server at the same time. Microsoft's SMB troubleshooting guide keeps the roles strict: the SMB Server hosts the file system, and the SMB Client accesses the share. That terminology is practical because the client log answers questions about the connection and process, while the server list answers questions about the issued handle. One error screenshot replaces neither source.

Reproduce the issue on a copy of the same type and similar size, never on the live central model. The repeatable sequence should identify the operation: open, modify, save, close, disconnect the network at a chosen point, and inspect the resulting state. Run that test in an approved window because deliberately breaking a write can damage the test file and affect the share.

Storage must support the chosen collaboration method

A shared drive, a synchronized folder, and a CAD collaboration system provide different guarantees. An SMB server coordinates access to one server copy. A synchronization service often keeps local copies on each computer and resolves conflicts later. A specialized platform manages transactions, versions, or ownership under application rules. Replacing one method with another without checking support creates locks, duplicates, and inconsistent central models.

Before placing a project, create a matrix for the exact CAD version: permitted protocol, supported server operating systems or NAS, latency requirements, and rules for central models, external references, backups, and antivirus software. Use the CAD and storage vendors' documentation as the source. Successfully opening a small file does not prove that concurrent writing is correct.

For branch offices, opening one file share across a slow WAN or arbitrary VPN is especially tempting. Speed is only part of the problem. A long operation increases the period in which an interruption can leave an unfinished transaction, local cache, or temporary ownership. If the application offers a server or cloud worksharing mode for a distributed team, compare it with ordinary SMB using the official support matrix, not the convenience of a mapped drive letter.

The infrastructure must be observable: an administrator can see open files and client sessions, a time service keeps nodes synchronized, logs remain available long enough for investigation, and backups are tested by restoring them. A storage snapshot is not the same as a valid backup of an active central model if the application requires operations to stop or provides its own archival method.

When designing such an environment, GSE.kz can bring servers, workstations, system integration, and round-the-clock support into one managed configuration. The collaboration protocol still has to follow the requirements of the CAD product in use, not a generic hardware description.

Project rules prevent most recurring locks

The operating procedure should describe what happens before an error, during it, and after recovery. A useful document fits on one page and names concrete roles, paths, and commands. A long policy that an engineer will not open during a failure does not control access.

Set these rules:

1. The project has one approved working path; archive, delivery, and local copies are clearly labeled and never edited in parallel.
2. Every participant uses a personal network account and a unique identity in the CAD or BIM system.
3. Before sleep, VPN disconnection, restart, or departure, the user saves, synchronizes, relinquishes ownership, and closes the application.
4. Only a designated administrator may force-close a server handle after confirmation from the owner and BIM coordinator.
5. Updates, migrations, and backup operations on central models run in an announced window with no active users.

Provide a communication channel with a short template: exact path, operation, error text, time, user, computer, and whether unsaved changes exist. That report lets an administrator run the exact query immediately. A message saying that the drawing is stuck again forces everyone to collect the same fields and extends downtime.

For ordinary files that the application cannot safely let several people edit, introduce an explicit check-out through the project log or document management system. This is an organizational lock, but it prevents simultaneous work before SMB has to reject it. Do not use a text file named busy.txt as the only control because it becomes stale like any other manual flag.

Decide separately who determines the fate of an unsynchronized local copy. The storage administrator understands sessions and handles but cannot assess engineering changes. The BIM coordinator understands the model but should not terminate network sessions by guesswork. The work owner confirms saving. A forced close rests on all three facts, even when two people cover the three roles.

Treat recurrence as an infrastructure incident

If the same lock returns, the cause has not been removed. An incident record should connect the file path, FileId, SessionId, account, client computer, CAD version, network state, and action taken. Without that connection, ten similar tickets appear to be ten unrelated accidents.

Group cases by workstation and user first. One computer points toward a process, CAD extension, driver, network, or power policy. One project across several computers points toward the model structure, an external reference, support folder, or collaboration method. Several projects on one storage system require inspection of server events, updates, protection, backups, and the network path.

Do not measure only the number of errors. Useful measures include time from the message to owner identification, the share of files released normally, the count of forced closes, and cases where changes were lost or recovered. A rise in forced closes with the same ticket count means the team learned to apply a risky command faster, not that the system improved.

After every forced intervention, leave a short outcome: who confirmed the save, which handle was closed, how the model was checked, and what observation will help prevent recurrence. If the cause is unknown, record that fact and arrange data collection for the next occurrence. Do not hide missing evidence behind a generic 'network issue' label.

For routine monitoring, preserve a sample of open files before and after the working day, but do not turn it into a list of offenders. Look for unusually long opens, recurrence from one client address, and sessions that survive application exit. A threshold must reflect real operations: publishing a set and synchronizing a large model naturally take longer than editing one sheet. Observe normal behavior first, then alert only on genuinely unusual cases. Never close handles automatically based on age: a long session may be healthy, and a forced command cannot know whether changes were saved. An alert should bring an administrator to the owner check, not make the decision automatically.

A good first technical deliverable is a saved Get-SmbOpenFile query filtered by exact path, paired with a clear responsibility log. The next deliverable follows the observed pattern: workstation configuration, a repaired network segment, a CAD update, replacement of unsupported storage, or a refined Revit procedure. The error stops being mysterious when each action rests on a known owner, a specific lock layer, and verified data state.