Corregir errores de autenticación de Azure File Storage — NetDrive

Un administrador de TI gestiona cinco recursos compartidos de Azure File Storage montados como letras de unidad en un host Windows Server RDS — uno por departamento, cada uno trasladado desde un antiguo servidor de archivos local. El lunes por la mañana, el recurso compartido de Finance arroja un error de autenticación en NetDrive mientras los otros cuatro se reconectan con normalidad. Si nada ha cambiado en la configuración de montaje desde el viernes, suele significar que las credenciales o el propio recurso compartido han cambiado, no NetDrive.

Monta Azure File Storage como una letra de unidad persistente

NetDrive hace que Google Drive, OneDrive, S3, SFTP, WebDAV y más aparezcan como unidades nativas en Windows y macOS — sin sincronizar, sin descargas completas.

• Conéctate con una clave de cuenta o un token SAS de alcance limitado
• El montaje automático al arrancar deja el recurso listo antes de iniciar sesión
• La licencia de equipo permite a un admin distribuir credenciales a cada máquina

WindowsmacOS

Descargar NetDrive →

Prueba gratuita. Planes de por vida y de suscripción disponibles.

Azure File Storage frente a Azure Blob — mismo error, causa distinta

NetDrive trata Azure File Storage y Azure Blob Storage como tipos de conexión independientes, y sus fallos de autenticación se originan en lugares ligeramente distintos. Blob Storage apunta a un contenedor; File Storage apunta a un recurso compartido de archivos con nombre, de estilo SMB, dentro de una cuenta de almacenamiento. Una unidad basada en File Storage necesita tres valores para reconectarse correctamente — el nombre de la cuenta de almacenamiento, la credencial (clave de cuenta o token SAS) y el nombre exacto del recurso compartido —, así que hay tres puntos donde puede originarse un fallo del tipo “funcionaba la semana pasada, hoy no”.

Comprobación 1: token SAS caducado o clave de cuenta rotada

Esta es la causa más común y la más rápida de descartar.

1. En el Azure Portal, abre la cuenta de almacenamiento detrás de la unidad con fallos y comprueba con qué tipo de credencial está configurada.
2. Token SAS: ve a Security + networking → Shared access signature y confirma que la Expiry date no ha pasado. Un token generado en la configuración inicial con una caducidad de 90 días deja de funcionar silenciosamente tres meses después, sin ningún aviso previo.
3. Clave de cuenta: ve a Security + networking → Access keys y comprueba si key1 o key2 se regeneró recientemente — a menudo porque otro administrador rota las credenciales como mantenimiento rutinario, sin darse cuenta de que otros cuatro servicios todavía referencian el valor antiguo.
4. Genera un nuevo token SAS con alcance limitado al servicio File (con al menos permisos Read, Write, List, Create, Delete), o copia la clave de cuenta actual.
5. Abre NetDrive → haz clic en el icono del engranaje de la unidad afectada en Drive Manager para abrir su configuración de conexión, pega la nueva credencial y haz clic en Save.

Comprobación 2: reglas de firewall de la cuenta de almacenamiento

Si la credencial es correcta y la unidad sigue sin autenticarse, lo siguiente son las reglas de red de la cuenta de almacenamiento.

1. En el Azure Portal, abre Networking → Firewalls and virtual networks para la cuenta de almacenamiento.
2. Si está configurado como Enabled from selected virtual networks and IP addresses en lugar de All networks, Azure rechaza el intento de conexión antes incluso de evaluar la credencial — algo que, desde el lado de NetDrive, se ve idéntico a una clave incorrecta.
3. Confirma la IP pública actual de la máquina y añádela al rango permitido, o relaja la regla si ese recurso compartido no necesita restricción por IP.

Una máquina con conexión residencial o de sucursal con IP dinámica suele ser reincidente en esto: la regla era correcta cuando se añadió, y el proveedor de internet ha asignado desde entonces una dirección distinta.

Comprobación 3: el recurso compartido se renombró o se eliminó

A diferencia de un contenedor Blob, un recurso compartido de File Storage se puede renombrar, eliminar y volver a crear bajo la misma cuenta de almacenamiento sin que cambien las propias credenciales de la cuenta — lo que significa que la clave de cuenta o el token SAS siguen autenticando correctamente, pero NetDrive no encuentra el recurso al que apuntaba originalmente. En el Azure Portal, ve a Data storage → File shares de la cuenta de almacenamiento y confirma que el nombre del recurso coincide exactamente, mayúsculas incluidas, con lo introducido en la configuración de conexión de NetDrive. Si el recurso se recreó tras eliminarse, actualiza el campo del nombre del recurso en NetDrive aunque el resto de credenciales no haya cambiado.

Confirmar la corrección

Después de actualizar la credencial, la regla de firewall o el nombre del recurso, vuelve a conectar la unidad y comprueba que realmente está sirviendo archivos y no solo mostrando “Connected” en la lista de unidades.

Abre la unidad en el explorador de archivos y lista una carpeta con archivos que reconozcas. Si el listado se rellena y un archivo se abre sin errores, la credencial, la ruta de red y el nombre del recurso son correctos.

Resumen

Los fallos de autenticación de Azure File Storage en NetDrive se deben, con mucha más frecuencia, a un token SAS caducado, una clave de cuenta rotada, una regla de firewall de la cuenta de almacenamiento o un recurso renombrado, que a un error tipográfico en la configuración inicial — revisa primero las credenciales, que se descartan más rápido, y luego la red. Para la guía de conexión inicial, consulta Montar Azure File Storage en Windows con NetDrive; si la unidad en cuestión usa en realidad contenedores Blob en lugar de un recurso compartido de archivos, corregir errores de autenticación de Azure Blob cubre ese caso equivalente.

— Casey, NetDrive