PR: Export to network folder permission problem
- Dominant language
- C#
- Stars
- 637
- Forks
- 225
- PR merge metrics
- No merged PRs in 30d
Description
### Problem Description
Expected behavior: Exporting IFC to a network share should succeed when the user has write permission to that folder, as it did in Revit 2025 and earlier.
Actual behavior: Starting an IFC export to a network path is blocked before it begins, with the "no write access" message. The same Windows user can write to the folder normally (e.g. via Explorer), and exporting to a local path works fine. The problem is specific to network locations — in our case an SMB share hosted on a Windows Server.
CanWriteFilesInDirectory in IFCCommandOverrideApplication.cs validates write access by reading the directory ACLs via GetAccessControl and matching the rule IdentityReference SIDs against the current WindowsIdentity. On our network the SIDs do not correspond to the local Windows account SIDs, so no rule ever matches and isAllowed stays false.
This appeared with the Revit 2026.1 addon. The write-access pre-check did not exist in the 25.4.x addon (Revit 2025) or earlier, where network exports worked without issue.
Steps to reproduce:
1. Access a network share on a Windows Server (e.g. \\192.168.1.200\share) where the current Windows user has write permission.
2. In Revit 2027, run Export → IFC and choose that network folder as the destination.
3. The export is rejected with the no-write-access dialog, even though writing to that folder works outside Revit.
Suggested fix: Keep the existing ACL-based check for local paths, but for network/UNC paths (where SID matching against the local identity is unreliable) fall back to an actual write attempt (e.g. create a temp file with FileOptions.DeleteOnClose and return success/failure).
I have a local workaround that simply replaces the ACL check entirely with the write attempt for all paths, which fixed the issue for us.
### Revit Version
2027.0.x
### IFC for Revit Addon Version
27.0.1.1
### Windows Version
11 25H2
Contributor guide
Research direction
Start in IFCCommandOverrideApplication.cs at CanWriteFilesInDirectory and trace the pre-export write-access check. Reproduce with a writable UNC/SMB path and a local path, then preserve the existing local ACL behavior while making network exports use an actual write check. Done means a user with write permission can export to the network folder without the no-write-access dialog.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- desktop
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 68/100