Before creating a new issue, please confirm:
On which framework/platform are you having an issue?
React
Which UI component?
Storage
How is your app built?
Vite
What browsers are you seeing the problem on?
Chrome
Which region are you seeing the problem in?
Japan
Please describe your bug.
Issue 1: StorageBrowser doesn't display folders when using allow.groups() only
Description:
When using allow.groups() for storage access control, StorageBrowser shows "No folders or files" even though the user belongs to the specified group and has proper IAM permissions.
Environment:
@aws-amplify/ui-react-storage: ^3.13.1
aws-amplify: ^6.6.6
Amplify Gen 2
Steps to Reproduce:
Define storage with group-based access:
export const storage = defineStorage({
name: 'myProjectFiles',
access: (allow) => ({
'foo/': [
allow.groups(['Admins']).to(['read','write', 'delete']),
allow.groups([‘user']).to(['read'])
]
})
});
Deploy and verify IAM policies are correctly created
Log in as a user who belongs to the Admins group
Open StorageBrowser
Expected Behavior:
StorageBrowser should display the folders that the user's group has access to.
Actual Behavior:
StorageBrowser shows "No folders or files" message.
Attempted Solutions:
We tried to grant root-level list permissions using wildcard patterns, but these cause deployment errors:
// ❌ Deployment fails with these patterns:
'': [allow.groups(['Admins']).to(['list'])]
'/': [allow.groups(['Admins']).to(['list'])]
Both '' and '/' patterns result in deployment errors, making it impossible to grant root-level list permissions to groups.
Workaround:
Adding allow.authenticated.to(['list']) makes folders visible:
'foo/': [
allow.authenticated.to(['list']), // Required for StorageBrowser to show folders
allow.groups(['Admins']).to(['read','write', 'delete']),
allow.groups(['user']).to(['read'])
]
Root Cause:
StorageBrowser's client-side logic requires authenticated permission in amplify_outputs.json to display folders, even when users have group-based permissions. This appears to be a limitation in how StorageBrowser interprets group-based access rules.
Additional Context:
IAM policies are correctly generated with proper permissions
Direct API calls (using uploadData, remove, list from aws-amplify/storage) work correctly with group permissions
The issue is specific to StorageBrowser's UI display logic
Root-level wildcard patterns ('' and '/') cannot be used with allow.groups() due to deployment errors
Issue 2: StorageBrowser shows incorrect permissions and disables actions for allow.groups() users
Description:
When using allow.groups() with write and delete permissions, StorageBrowser displays "Read" permission only and disables the three-dot menu (actions menu), even though the user has full read/write/delete permissions via IAM.
Environment:
@aws-amplify/ui-react-storage: ^3.13.1
aws-amplify: ^6.6.6
Amplify Gen 2
Steps to Reproduce:
Define storage with group-based access including write and delete:
export const storage = defineStorage({
name: 'myProjectFiles',
access: (allow) => ({
'foo/*': [
allow.authenticated.to(['list']),
allow.groups(['Admins']).to(['read','write', 'delete'])
]
})
});
Deploy and verify IAM policies include s3:PutObject and s3:DeleteObject
Log in as a user in the Admins group
Navigate to a folder in StorageBrowser
Expected Behavior:
Permissions column should show "Read, Write, Delete"
Three-dot menu should be enabled for file operations
Actual Behavior:
Permissions column shows "Read" only
Three-dot menu is grayed out/disabled
No upload or delete options are available in the UI
Verification:
Direct API calls confirm the user has proper permissions:
// These work correctly:
await uploadData({ path: 'foo/test.txt', data: file }).result; // ✅ Success
await remove({ path: 'foo/test.txt' }); // ✅ Success
Root Cause:
StorageBrowser's UI does not correctly interpret groupsAdmins permissions from amplify_outputs.json. The generated amplify_outputs.json contains:
"groupsAdmins": [
"get",
"list",
"write",
"delete"
]
But StorageBrowser's UI only recognizes these permissions when they come from authenticated rules, not from groups rules.
Impact:
Users cannot use StorageBrowser's built-in UI for file operations (upload, delete) even though they have the necessary IAM permissions. This forces developers to implement custom UI for these operations.
Additional Context:
IAM policies are correct and functional
The issue is purely in StorageBrowser's client-side permission interpretation
This affects the usability of group-based access control in StorageBrowser
What's the expected behaviour?
StorageBrowser should display the folders that the user's group has access to.
The Permissions column should show "Read, Write, Delete".
The action menu (three-dot menu) should be enabled for file operations.
Help us reproduce the bug!
export const storage = defineStorage({
name: 'myProjectFiles',
access: (allow) => ({
'foo/*': [
allow.authenticated.to(['list']),
allow.groups(['Admins']).to(['read','write', 'delete'])
]
})
});
Code Snippet
// Put your code below this line.
Console log output
No response
Additional information and screenshots
No response
Before creating a new issue, please confirm:
On which framework/platform are you having an issue?
React
Which UI component?
Storage
How is your app built?
Vite
What browsers are you seeing the problem on?
Chrome
Which region are you seeing the problem in?
Japan
Please describe your bug.
Issue 1: StorageBrowser doesn't display folders when using allow.groups() only
Description:
When using allow.groups() for storage access control, StorageBrowser shows "No folders or files" even though the user belongs to the specified group and has proper IAM permissions.
Environment:
@aws-amplify/ui-react-storage: ^3.13.1
aws-amplify: ^6.6.6
Amplify Gen 2
Steps to Reproduce:
Define storage with group-based access:
export const storage = defineStorage({
name: 'myProjectFiles',
access: (allow) => ({
'foo/': [
allow.groups(['Admins']).to(['read','write', 'delete']),
allow.groups([‘user']).to(['read'])
]
})
});
Deploy and verify IAM policies are correctly created
Log in as a user who belongs to the Admins group
Open StorageBrowser
Expected Behavior:
StorageBrowser should display the folders that the user's group has access to.
Actual Behavior:
StorageBrowser shows "No folders or files" message.
Attempted Solutions:
We tried to grant root-level list permissions using wildcard patterns, but these cause deployment errors:
// ❌ Deployment fails with these patterns:
'': [allow.groups(['Admins']).to(['list'])]
'/': [allow.groups(['Admins']).to(['list'])]
Both '' and '/' patterns result in deployment errors, making it impossible to grant root-level list permissions to groups.
Workaround:
Adding allow.authenticated.to(['list']) makes folders visible:
'foo/': [
allow.authenticated.to(['list']), // Required for StorageBrowser to show folders
allow.groups(['Admins']).to(['read','write', 'delete']),
allow.groups(['user']).to(['read'])
]
Root Cause:
StorageBrowser's client-side logic requires authenticated permission in amplify_outputs.json to display folders, even when users have group-based permissions. This appears to be a limitation in how StorageBrowser interprets group-based access rules.
Additional Context:
IAM policies are correctly generated with proper permissions
Direct API calls (using uploadData, remove, list from aws-amplify/storage) work correctly with group permissions
The issue is specific to StorageBrowser's UI display logic
Root-level wildcard patterns ('' and '/') cannot be used with allow.groups() due to deployment errors
Issue 2: StorageBrowser shows incorrect permissions and disables actions for allow.groups() users
Description:
When using allow.groups() with write and delete permissions, StorageBrowser displays "Read" permission only and disables the three-dot menu (actions menu), even though the user has full read/write/delete permissions via IAM.
Environment:
@aws-amplify/ui-react-storage: ^3.13.1
aws-amplify: ^6.6.6
Amplify Gen 2
Steps to Reproduce:
Define storage with group-based access including write and delete:
export const storage = defineStorage({
name: 'myProjectFiles',
access: (allow) => ({
'foo/*': [
allow.authenticated.to(['list']),
allow.groups(['Admins']).to(['read','write', 'delete'])
]
})
});
Deploy and verify IAM policies include s3:PutObject and s3:DeleteObject
Log in as a user in the Admins group
Navigate to a folder in StorageBrowser
Expected Behavior:
Permissions column should show "Read, Write, Delete"
Three-dot menu should be enabled for file operations
Actual Behavior:
Permissions column shows "Read" only
Three-dot menu is grayed out/disabled
No upload or delete options are available in the UI
Verification:
Direct API calls confirm the user has proper permissions:
// These work correctly:
await uploadData({ path: 'foo/test.txt', data: file }).result; // ✅ Success
await remove({ path: 'foo/test.txt' }); // ✅ Success
Root Cause:
StorageBrowser's UI does not correctly interpret groupsAdmins permissions from amplify_outputs.json. The generated amplify_outputs.json contains:
"groupsAdmins": [
"get",
"list",
"write",
"delete"
]
But StorageBrowser's UI only recognizes these permissions when they come from authenticated rules, not from groups rules.
Impact:
Users cannot use StorageBrowser's built-in UI for file operations (upload, delete) even though they have the necessary IAM permissions. This forces developers to implement custom UI for these operations.
Additional Context:
IAM policies are correct and functional
The issue is purely in StorageBrowser's client-side permission interpretation
This affects the usability of group-based access control in StorageBrowser
What's the expected behaviour?
StorageBrowser should display the folders that the user's group has access to.
The Permissions column should show "Read, Write, Delete".
The action menu (three-dot menu) should be enabled for file operations.
Help us reproduce the bug!
export const storage = defineStorage({
name: 'myProjectFiles',
access: (allow) => ({
'foo/*': [
allow.authenticated.to(['list']),
allow.groups(['Admins']).to(['read','write', 'delete'])
]
})
});
Code Snippet
// Put your code below this line.Console log output
No response
Additional information and screenshots
No response