Skip to main content

Google Drive Permission Changes - File System to Google Workspace

Permission Migration Watchpoints

Important Change — Effective Mid-February 2026
Google Drive has changed how permissions work. Folders that were previously hidden from certain users on your file server will now appear greyed out in Google Drive. Users still cannot access the content — only the visibility has changed.


What's Changing?

When migrating from Windows File System (NTFS) to Google Drive, the way restricted folders appear to users will change. This affects folders where:

  • Deny permissions are applied (explicit Deny ACEs)
  • Inheritance is disabled and users are removed from the ACL
  • Files have different permissions than their parent folder

Key Point: This is a Google platform change, not a CloudM limitation. Google has redesigned how restricted folders work based on user feedback that hidden folders caused confusion.

The Change Explained

ScenarioBefore (Windows)After (Google Drive)
User denied access to a subfolderFolder is hidden — user cannot see itFolder is greyed out — user can see it but cannot access
User denied access to a fileFile is hidden — user cannot see itFile is in a greyed-out wrapper folder
User has same or more access on childNormal visibilityNormal visibility (No change)

Understanding NTFS Permissions

NTFS (Windows) permissions work differently from Google Drive. Here are the key concepts that affect migration:

ConceptHow It WorksMigration Impact
Allow vs DenyDeny permissions always override Allow permissionsDenied users see folders greyed out
InheritancePermissions flow down from parent foldersSame behaviour in Google Drive
Disabled InheritanceChild folder has completely different ACLExcluded users see folder greyed out
Nested GroupsUser can be in multiple groups with conflicting permissionsDeny on any group = greyed out

Example 1: Explicit Deny Permission

This example shows what happens when a user is explicitly denied access to a subfolder.

Scenario

The Marketing_Group has Modify access to D:\Marketing\. However, User A (who is in Marketing_Group) has an explicit Deny on the D:\Marketing\Internal\ subfolder.

Source (Windows File Server)

📁 D:\Marketing (Allow: Marketing_Group)
  📁 Campaigns (Inherited)
  📁 Internal (Deny: User A)

User A sees: "Marketing" and "Campaigns" folders only.
"Internal" folder is completely hidden due to Deny ACE.

Target (Google Drive)

📁 Marketing (Marketing_Group: Editor)
  📁 Campaigns (Marketing_Group: Editor)
  📁 Internal [GREYED OUT] (User A: No Access)

User A sees: All three folders.
"Internal" appears greyed out and cannot be opened.

What this means: User A will now see that an "Internal" folder exists, but they still cannot access it. The Deny permission is preserved — only the visibility has changed.


Example 2: Disabled Inheritance

This example shows what happens when a folder has inheritance disabled, removing access for certain users.

Scenario

Domain Users have Read access to D:\Company\. The D:\Company\HR\ subfolder has inheritance disabled — only the HR_Admins group is in its ACL.

Source (Windows File Server)

📁 D:\Company (Allow: Domain Users)
  📁 Public (Inherited)
  📁 HR (Inheritance Disabled - Allow: HR_Admins only)

Domain Users see: "Company" and "Public" folders only.
"HR" folder is hidden (they're not in the ACL).

Target (Google Drive)

📁 Company (Domain Users: Viewer)
  📁 Public (Domain Users: Viewer)
  📁 HR [GREYED OUT] (Domain Users: No Access)

Domain Users see: All three folders.
"HR" appears greyed out and cannot be opened.

Why does this happen? When inheritance is disabled in Windows, users not in the child folder's ACL simply don't see it. Google Drive's new model preserves the restriction but makes the folder visible (greyed out) to maintain folder structure context.


Example 3: File-Level Deny (Wrapper Folder)

When a specific file has a Deny ACE, a wrapper folder is created to contain it.

Scenario

User A has Modify access to D:\Projects\. However, the file budget.xlsx has an explicit Deny for User A.

Source (Windows File Server)

📁 D:\Projects (Allow: User A)
  📄 project-plan.docx (Inherited)
  📄 budget.xlsx (Deny: User A)

User A sees: Projects folder and project-plan.docx only.
budget.xlsx is hidden due to Deny ACE.

Target (Google Drive)

📁 Projects (User A: Editor)
  📄 project-plan.docx (User A: Editor)
  📁 _budget.xlsx/ [GREYED OUT] (User A: No Access)
      📄 budget.xlsx

User A sees: Projects folder, project-plan.docx, and a greyed-out wrapper folder.
The wrapper folder name reveals the file name.

Why wrapper folders? Google Drive no longer allows files to have more restrictive permissions than their parent folder. The wrapper folder is created to enforce the Deny while keeping the file in its logical location.


Example 4: Nested Group Conflict

NTFS groups can be nested, creating complex permission scenarios. Deny always wins.

Scenario

User A is in the Sales-US group. Sales-US is a member of Sales-Global. The D:\Sales\Confidential\ folder has a Deny ACE for Sales-US.

Group Membership: User A → member of → Sales-US → member of → Sales-Global

FolderSales-GlobalSales-USUser A Effective
/Sales/Allow: Modify(inherited)Editor via Sales-Global
/Sales/Confidential/Allow: ModifyDenyNo Access — Deny wins

Result: User A can access /Sales/ but sees /Sales/Confidential/ greyed out. Even though Sales-Global has Allow access, the Deny on Sales-US takes precedence.


Scenarios With No Change

Many NTFS permission structures migrate without any visible change:

ScenarioResult
Standard inheritance (no Deny, inheritance enabled)No change — Permissions migrate directly
User has more access on child than parentNo change — Google supports permission upgrades
User added to child folder ACL (not on parent)No change — Direct share applied
All users have Allow permissions throughoutNo change — Standard inheritance works

Shared Drive Considerations

If your migration destination is a Shared Drive, there are additional considerations beyond the visibility changes described above.

Manager Visibility

Users with the Manager role (organizers) on a Shared Drive will always see Limited Access folders as greyed out. This is Google platform behaviour and cannot be changed. Regular members (Content Managers, Contributors, Viewers) will see restricted folders as greyed out and cannot access them.

Permission Placement Settings

When migrating to a Shared Drive, CloudM Migrate provides two settings that control where permissions are applied:

SettingOptionsWhat It Controls
Shared Drive Folder PermissionsFolder, Root, NoneWhere folder-level NTFS permissions are applied
Shared Drive File PermissionsFile, Root, NoneWhere file-level NTFS permissions are applied

How Each Option Works

OptionBehaviour
Folder / FilePermissions are applied to each individual folder or file. Each item's permissions match the source NTFS permissions exactly.
RootThe top-level source folder's permissions are applied to the Shared Drive root. Due to Google Drive's expansive access model, these permissions cascade to all content in the drive, establishing each user's minimum access level. Subfolder permissions can grant additional access above this baseline but cannot restrict below it.
NonePermissions are not applied for that item type.

Recommended Configuration

For most NTFS migrations to Shared Drives, we recommend Folder for folder permissions and File for file permissions. This produces the most accurate permission mapping — each item's access matches the source.

Use Root only when the top-level folder's permissions represent the access level you want users to have across the entire Shared Drive. Be aware that root-level permissions cascade to all content — a user with Viewer access at the root will have Viewer access to every folder and file in the drive.

Note: The examples in this document show permissions applied to individual folders and files, which reflects the Folder / File setting. With the Root setting, top-level permissions cascade to the entire drive, so users will have at minimum the access level of the top-level folder on all items.


Pre-Migration Recommendations

To minimise unexpected visibility changes, consider these steps before migration:

1. Review Sensitive Folder Names

Folders with Deny ACEs or disabled inheritance will be visible (greyed out) after migration. If any folder names contain sensitive information, consider renaming them before migration.

Examples of potentially sensitive folder names:

  • D:\HR\Redundancy Plans 2026 — Consider renaming to HR-Confidential-001
  • D:\Finance\Salary Reviews — Consider renaming to Finance-Restricted
  • D:\Legal\Acquisition Target — Consider renaming to Legal-Confidential

2. Audit Deny Permissions

Run a report of all Deny ACEs in your file system. These are the primary triggers for greyed-out folders.

3. Review Disabled Inheritance

Identify folders where inheritance has been disabled. Users excluded from these folders' ACLs will see them greyed out.

4. Communicate with End Users

Inform users that they may see greyed-out folders after migration. Emphasise that:

  • They still cannot access the content
  • This is Google's intended design
  • The folder structure is preserved for easier navigation

Frequently Asked Questions

Q: Can users access the greyed-out folders?
A: No. Greyed-out folders indicate "Limited Access" — users can see the folder exists but cannot open it, view its contents, or access any files within it. The Deny permission is fully enforced.

Q: Why can users now see folder names they couldn't see before?
A: This is a Google design decision based on user research. Google found that completely hidden folders caused confusion — users didn't understand why some colleagues could see items they couldn't. Making restricted folders visible (but greyed out) provides clarity about the folder structure while maintaining security.

Q: Can we hide the greyed-out folders?
A: No. Google's new permission model does not support hiding folders from users who have access to the parent. This is a platform-level change that affects all Google Drive usage, not just migrations.

Q: What happens to my Deny ACEs?
A: Deny permissions are preserved in terms of access control. Users who were denied access on Windows will still be unable to access the content in Google Drive. The only change is that they can now see that the folder exists (greyed out).

Q: What is a "wrapper folder" for files?
A: Google Drive now requires files to have the same or more permissive access than their parent folder. When a file has a Deny ACE, we create a wrapper folder (named after the file with an underscore prefix) to contain it. This wrapper folder is set to "Limited Access" and appears greyed out to denied users.

Q: How are nested groups handled?
A: The migration engine resolves all Active Directory group memberships and calculates effective permissions. If a user is denied via any group they belong to, that Deny takes precedence — this is standard NTFS behaviour, and it's preserved in Google Drive via the greyed-out folder.

Q: Will this affect my migration timeline?
A: Migrations with complex NTFS permissions (many Deny ACEs or disabled inheritance) may take slightly longer due to the additional processing required. However, this approach (Limited Access) has the lowest performance impact compared to alternative methods.


Summary

What's HappeningWhyUser Impact
Denied folders appear greyed outGoogle's new permission modelFolder names visible, content still protected
Denied files get wrapper foldersFiles must inherit from parent folderFile names visible via wrapper, content protected
Folder hierarchy preservedMaintains navigation contextUsers see familiar structure
Deny permissions honouredAccess control preservedSecurity unchanged, only visibility different
Was this article helpful?
0 out of 0 found this helpful