(Doc+) Recovery ".kibana*" indices write block

docs/setup/access.asciidoc

@@ -66,3 +66,35 @@ For example:
 * When one or more {kib}-backing indices are unhealthy, the `index_not_green_timeout` error appears.
 
 For more information, refer to our https://www.elastic.co/blog/troubleshooting-kibana-health[walkthrough on troubleshooting Kibana Health].
+
+[float]
+[[index-write-block]]
+=== Troubleshoot {kib} index write block
+
+{kib} temporarily sets an {ref}/index-modules-blocks.html[{es} index `write` block] during its upgrade's <<saved-object-migrations,Saved Object Migration>>. If it is unable to successfully complete this migration, it may not reset this override for its `.kibana*` backing indices and so the {kib} logs will error variations like 
+
+[source,text]
+----
+[.kibana] blocked by: [FORBIDDEN/8/index write (api)];: cluster_block_exception Root causes: cluster_block_exception: index [.kibana] blocked by: [FORBIDDEN/8/index write (api)];
+----
+
+This can occur when 
+
+* an {ess} or {ece} Deployment upgrade plan is cancelled by user
+
+* {es} is experiencing an underlying issue during {kib}'s migration, most commonly related to {es} errors 
++
+* {ref}/size-your-shards.html#troubleshooting-max-shards-open[`this action would add [x] total shards, but this cluster currently has [y]/[z] maximum shards open`]
+* {ref}/fix-watermark-errors.html[`disk usage exceeded flood-stage watermark, index has read-only-allow-delete block`]
+
+The underlying {es} issue should be resolved first. Afterwards, you may need to manually resolve by either
+
+* removing the {es} index write block via an {ref}/indices-update-settings.html[update index settings]
++ 
+[source,console]
+----
+PUT .kibana*/_settings?expand_wildcards=all
+{"index.blocks.write":null }
+----
+
+* <<upgrade-migrations-rolling-back,rollback to previous version of {kib}>>