Overview
If the same business file opens for one employee but not another, the file itself may be healthy. The difference is often the user's account, permission path, licensing, application version, sync state, or the location from which the file is being opened.
Why this happens
Access may come directly from SharePoint, OneDrive, Google Drive, a Shared Drive, a network share, or an application-specific permission. Two employees can appear to have the same job role while receiving access through different groups, links, licenses, sync clients, or local cached copies.
Before you begin
- Identify the exact file and its authoritative business location.
- Confirm which employee can open it and which employee cannot.
- Record the exact error message and the application being used.
- Do not duplicate sensitive files or grant Everyone access as a workaround.
Click-by-click troubleshooting
Step 1: Confirm both employees are opening the same file
Action: Compare the full file location or sharing URL for both employees. For cloud files, open the authoritative SharePoint, OneDrive, Google Drive, or Shared Drive location in a browser instead of relying on Recent files.
Why this matters: Recent-file lists and synced folders can point to different copies with similar names.
What to look for: Confirm the same site, library, folder, file name, and path.
Expected result: Both users should be testing the exact same authoritative file.
Step 2: Test access in the browser
Action: Have the affected employee sign in to the business service in a private browser window and open the file from its web location.
Why this matters: Browser testing separates service permissions from desktop sync and local application problems.
What to look for: Look for Access denied, Request access, file not found, license prompts, or successful browser access.
Expected result: If browser access works, focus next on the desktop application or sync client. If browser access fails, focus on identity and permissions.
Step 3: Verify the affected employee's signed-in identity
Action: In the browser, select the profile icon and confirm the employee is signed in with the intended work account. In Microsoft 365 desktop apps, open File > Account and review the signed-in account.
Why this matters: Personal accounts, old work accounts, and guest identities can make a valid file appear unavailable.
What to look for: Confirm the exact email address and tenant or organization expected for the file.
Expected result: The employee should be using the business identity that is supposed to have access.
Step 4: Compare the permission source, not just the visible user name
Action: If you are authorized to review permissions, open the file or folder permissions in the owning service. In SharePoint, use Settings > Site permissions or Manage access. In Google Drive, use Share. Compare whether the working employee receives access directly or through a group.
Why this matters: The working employee may inherit access through a Microsoft 365 group, SharePoint group, Google Group, Shared Drive role, or parent folder that the affected employee does not have.
What to look for: Look for missing group membership, different role levels, broken inheritance, expired sharing links, or access granted to the wrong account.
Expected result: You should be able to explain exactly why the working employee has access and whether the affected employee should receive the same approved access path.
Step 5: Check the application and file type
Action: If browser access works but the desktop application fails, verify the application opens other files of the same type. In Microsoft 365 apps, open File > Account and confirm the product is activated. Check whether the file requires a specific application or version.
Why this matters: A permission problem and an application problem can produce similar user complaints.
What to look for: Look for unlicensed product messages, unsupported file types, protected-view prompts, add-in errors, or corruption warnings.
Expected result: The employee should be able to open a known-good file of the same type with the same application.
Step 6: Check sync state only after browser access is proven
Action: If the file is synced locally, open the OneDrive or Google Drive sync client and review its status. Compare the local path with the web path and confirm the file is fully synced.
Why this matters: A stale or conflicted local copy can fail even while the authoritative cloud file is healthy.
What to look for: Look for red X icons, paused sync, account mismatch, conflict copies, or a local file that has not downloaded.
Expected result: The local copy should correspond to the same cloud file and show a healthy sync state.
What to look for
- Browser fails and permissions differ: correct the approved access path.
- Browser works but desktop app fails: investigate application identity, activation, or file handling.
- Only the synced copy fails: investigate the sync client and local path.
- Users are opening different copies: establish the authoritative business location before changing permissions.
When to stop
When to contact IT
Contact IT if the required access is unclear, the affected user is missing expected group membership, the file contains sensitive data, the desktop application is unlicensed, or sync remains unhealthy after browser access is confirmed. Provide the file URL, affected account, working comparison account, exact error, and permission source if known.
Need help with this issue?
J3 Systems Group supports small businesses and nonprofits with Microsoft 365, Google Workspace, cybersecurity, devices, documentation, and day-to-day IT operations.
Contact J3 Systems GroupAuthoritative references
Vendor interfaces, licensing, and security guidance can change. Verify current platform behavior against the primary documentation below before making high-impact production changes.