diff --git a/tidb-cloud/migrate-from-mysql-using-data-migration.md b/tidb-cloud/migrate-from-mysql-using-data-migration.md
index d708402cb6502..fd2a58aff49c7 100644
--- a/tidb-cloud/migrate-from-mysql-using-data-migration.md
+++ b/tidb-cloud/migrate-from-mysql-using-data-migration.md
@@ -438,11 +438,16 @@ For production workloads, it is recommended to have a dedicated user for data du
 | `RELOAD` | Global | Ensures consistent snapshots during full dump |
 | `REPLICATION SLAVE` | Global | Enables binlog streaming for incremental data migration |
 | `REPLICATION CLIENT` | Global | Provides access to binlog position and server status |
+| `LOCK TABLES` | Tables | Required when the source is a managed MySQL service (such as Amazon RDS, Aurora, ApsaraDB RDS for MySQL, Azure Database for MySQL, or Google Cloud SQL) where `FLUSH TABLES WITH READ LOCK` is not permitted. In this case, DM falls back to `LOCK TABLES` for consistency during full data export. Not required for self-managed MySQL instances where FTWRL is available. |
 
 For example, you can use the following `GRANT` statement in your source MySQL instance to grant corresponding privileges:
 
 ```sql
+-- For self-managed MySQL:
 GRANT SELECT, RELOAD, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'dm_source_user'@'%';
+
+-- For managed MySQL (Amazon RDS, Aurora, etc.), also grant LOCK TABLES:
+GRANT SELECT, RELOAD, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'dm_source_user'@'%';
 ```
 
 #### Grant required privileges in the target TiDB Cloud cluster
diff --git a/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md b/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md
index 7f419a96114d7..ece9f52a3ef2b 100644
--- a/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md
+++ b/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md
@@ -94,6 +94,20 @@ Failed to create a schema in the downstream TiDB cluster. This error means that
 
 To resolve this issue, you can create a schema in the TiDB cluster based on a [supported collation](/character-set-and-collation.md#character-sets-and-collations-supported-by-tidb), and then resume the task by clicking **Restart**.
 
+### Error message: "LOCK TABLES ... Access denied"
+
+The full data export failed because the source database user does not have the `LOCK TABLES` privilege. This error typically occurs when migrating from a managed MySQL service (such as Amazon RDS, Aurora, ApsaraDB RDS for MySQL, Azure Database for MySQL, or Google Cloud SQL) where `FLUSH TABLES WITH READ LOCK` (FTWRL) is not permitted by the cloud provider. In this case, DM's default `consistency=auto` mode falls back to `LOCK TABLES` for data consistency during full export, which requires this privilege.
+
+> **Note:** This error can also occur on self-managed MySQL instances if FTWRL is unavailable for other reasons (for example, missing `RELOAD` privilege).
+
+To resolve this issue, grant the missing privilege to the migration user in the source MySQL database:
+
+```sql
+GRANT LOCK TABLES ON *.* TO 'dm_source_user'@'%';
+```
+
+Then resume the task by clicking **Restart**.
+
 ## Alerts
 
 You can subscribe to TiDB Cloud alert emails to be informed in time when an alert occurs.