- Más nuevo
- Más votos
- Más comentarios
I think the error is showing
The user’s identity and permissions (via IAM or SSO)
AND
QuickSight's internal "scopedown policy" logic for datasets — which restricts what rows, columns, or tables a user can access in row-level security (RLS) or restricted datasets.
Even if the user: Is Admin Owns the dataset and datasource Is covered by IAM policy assignments
...QuickSight still checks for scopedown policy metadata, and if it can't find a valid config post-permission change, it breaks access to that dataset for that user.
Recommended fix
Go to QuickSight Admin → Security & Permissions
Find the IAM or IAM Identity Center user
Create and assign a scopedown policy (even a permissive one)
Reopen or refresh the dataset
If the dataset works again, remove the scopedown policy
This "resets" the internal reference to scopedown metadata.
If the issue is isolated to a user, try reassigning the dataset:
aws quicksight update-data-set-permissions
--aws-account-id 123456789012
--data-set-id your_dataset_id
--grant-permissions Principal=arn:aws:quicksight:region:account:user/default/new_user,Actions=quicksight:DescribeDataSet,quicksight:UpdateDataSetPermissions
Then have the new user try editing or duplicating the dataset.
Also, this might help but its good for automation or bulk correction Rebuild via Asset Bundle Export (as you’re doing) You're already using this as a workaround — it re-creates the dataset and dependencies without the corrupted scopedown reference.
aws quicksight start-asset-bundle-export-job ... aws quicksight start-asset-bundle-import-job ...
This is effective but inefficient — good for automation or bulk correction.
Contenido relevante
- preguntada hace 24 días
- preguntada hace 4 meses
- preguntada hace 24 días
- preguntada hace 12 días
- OFICIAL DE AWSActualizada hace 2 meses
