[BUG] Bash session falls back to ephemeral (“Failed to mount the Azure file share”) after $HOME image is attached; intermittent across 5 file shares, 3 storage accounts, 2 subscriptions

Ouverte
#648 1 commentaire 0 réactions 1 personne assignée Voir sur GitHub

@priyaananthasankar y travaille déjà.

Depuis le 12/10/2026.

Évaluation

Cette issue n'a pas encore été évaluée.

Description

bug

To Reproduce

  1. Open Cloud Shell (Bash) with a working, previously mounted file share.
  2. Use it normally for one or more sessions (some ended by the 20-minute idle timeout).
  3. Open a new Cloud Shell session.
    The issue is intermittent. It recurs after anywhere from a few sessions to about 10 days. Reset User Settings plus remounting the same share restores service temporarily. Plain restarts don’t.

Observed Behavior

Requesting a Cloud Shell.Succeeded.
Connecting terminal...
Warning: Failed to mount the Azure file share. Your cloud drive won't be available.
Your Cloud Shell session will be ephemeral so no files or system changes will persist beyond your current session.

Checks run from the ephemeral session at each failure:

  • Storage account exists; firewall Allow; public and shared-key access at defaults
  • Share quota not exceeded; 0 open SMB handles (az storage share list-handle)
  • $HOME image (acc_.img) passes e2fsck -n: clean, 60%+ free
  • Microsoft.CloudShell, .Storage, .Resources, .ContainerInstance registered
  • Storage key retrievable; CLI token valid
  • userSettings/cloudconsole storageProfile points to the correct account and share

The platform attaches the image during the failed start, then falls back:
2026-09-23: image mounted 13:18:28 UTC, released 13:20:02 UTC -> ephemeral
(user login profile never executed on the image)
2026-10-02: image Last Modified 16:56:38 UTC during failed start
2026-10-12: image Last Modified 14:18:44 UTC during failed start (ACC_LOCATION=WESTCENTRALUS)

Region is not the factor. Working sessions, logged from .bashrc, with storage in West US 2:
2026-10-02T18:35:34Z WESTCENTRALUS mounted
2026-10-02T20:04:33Z WESTCENTRALUS mounted
2026-10-08T17:50:48Z SOUTHCENTRALUS mounted
2026-10-08T19:01:12Z WESTUS2 mounted
2026-10-08T19:38:40Z WESTUS2 mounted
2026-10-09T15:05:18Z WESTUS2 mounted
2026-10-09T15:23:21Z WESTUS2 mounted
2026-10-12T13:30:08Z WESTCENTRALUS mounted
2026-10-12 ~14:18Z WESTCENTRALUS FAILED (ephemeral)

Expected behavior

Each new Bash session should mount the configured file share and $HOME image consistently, as it did for months before mid-September 2026. If a mount step fails, the session should report the specific cause instead of silently falling back to ephemeral.

Is this specific to Cloud Shell?

Yes. The persistent $HOME and clouddrive mount exist only in Cloud Shell. Azure CLI and the storage account work normally from the same ephemeral session and from outside Cloud Shell.

Interface information

Azure portal (https://portal.azure.com/), Cloud Shell pane. Chrome Version 154.0.8037.98 (Official Build) (64-bit)
on Windows 11 25H2 and 26H2.

Additional context

Reproduced on 5 file shares in 3 storage accounts across 2 subscriptions (one EA), with storage in East US and West US 2, including a $HOME containing only plain user data files.
~/.local/bin/rootless-docker-setup.sh runs at every session start (set -e) and appends a duplicate “Rootless docker specific environment variables” block to ~/.bashrc each session (183 accumulated on one image).
2026-09-23 18:02 UTC: the CLI access token wasn’t refreshed after expiry (“access token expiry ... is earlier than current UTC time”).
Possible pattern, unconfirmed: the session before the 2026-10-12 failure appears to have ended by idle timeout.
I can share account and session details privately. Could the team check the backend startup logs for the failed timestamps above?

Langage dominant
PowerShell
Étoiles
273
Forks
116
Métriques de merge des PR
Aucune PR mergée en 30 j

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de Azure/CloudShell

Toutes les issues de Azure/CloudShell

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.