Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Solución de problemas: problemas con el uso compartido de archivos
A continuación encontrará información sobre las acciones que debe realizar si experimenta problemas inesperados con recursos compartidos de archivos.
Temas
Los archivos compartidos SMB no permiten varios métodos de acceso diferentes
Varios archivos compartidos no pueden escribir en el bucket de S3 mapeado
Notificación de un grupo de registros eliminado cuando se utilizan registros de auditoría
Los cambios en un bucket de S3 no se reflejan en Storage Gateway
El rendimiento de su puerta de enlace disminuyó después de realizar una operación recursiva
El archivo compartido está bloqueado en el estado CREATING
Cuando el recurso compartido de archivos se está creando, el estado es CREATING. El estado pasa a ser a AVAILABLE una vez que se crea el recurso compartido de archivos. Si el recurso compartido de archivos se bloquea en el estado CREATING, haga lo siguiente:
Abra la consola de Amazon S3 en https://console.aws.amazon.com/s3/
. -
Asegúrese de que el depósito de S3 al que asignó su recurso compartido de archivos existe. Si el bucket no existe, créelo. Después de crear el bucket, el estado del recurso compartido de archivos pasa a ser AVAILABLE. Para obtener información sobre cómo crear un depósito de S3, consulte Crear un depósito en la Guía del usuario de Amazon Simple Storage Service.
-
Asegúrese de que el nombre de su bucket cumpla con las normas de denominación de bucket de Amazon S3. Para obtener más información, consulte Reglas para nombrar buckets en la Guía del usuario de Amazon Simple Storage Service.
nota
S3 File Gateway no admite buckets de Amazon S3 con puntos (
.
) en el nombre del bucket. -
Asegúrese de que la función de IAM que utilizó para acceder al bucket de S3 tenga los permisos correctos y compruebe que el bucket de S3 aparezca como recurso en la política de IAM. Para obtener más información, consulte Concesión de acceso a un bucket de Amazon S3.
No puedes crear un recurso compartido de archivos
-
Si no puede crear un recurso compartido de archivos porque su recurso compartido de archivos está bloqueado en el estado DE CREACIÓN, compruebe que el depósito de S3 al que lo asignó existe. Para obtener información acerca de cómo hacerlo, consulte El archivo compartido está bloqueado en el estado CREATING, más arriba.
-
Si el depósito de S3 existe, compruebe que AWS Security Token Service esté activado en la región en la que va a crear el recurso compartido de archivos. Si un token de seguridad no está activo, debe activarlo. Para obtener información sobre cómo activar un token mediante AWS Security Token Service, consulte Activación y desactivación del AWS STS en una AWS región en la Guía del usuario de IAM.
Los archivos compartidos SMB no permiten varios métodos de acceso diferentes
Los recursos compartidos de archivos SMB tienen las siguientes restricciones:
-
Cuando el mismo cliente intenta montar un recurso compartido de archivos SMB para el acceso de invitado y para Active Directory, se muestra el siguiente mensaje de error:
Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.
-
Un usuario de Windows no puede estar conectado a dos recursos compartidos de archivos SMB para el acceso de invitado y es posible que se le desconecte cuando se establezca una nueva conexión de acceso de invitado.
-
Un cliente de Windows no puede montar un recurso compartido de archivos SMB para el acceso de invitado y para Active Directory que se haya exportado por la misma gateway.
Varios archivos compartidos no pueden escribir en el bucket de S3 mapeado
No recomendamos configurar el depósito de S3 para permitir que varios recursos compartidos de archivos escriban en un depósito de S3. Este enfoque puede producir resultados impredecibles.
En su lugar, le recomendamos que solo un recurso compartido de archivos pueda escribir en cada bucket de S3. Puede crear una política de bucket para permitir que únicamente el rol asociado al recurso compartido de archivos escriba en el bucket. Para obtener más información, consulte Prácticas recomendadas para File Gateway.
Notificación de un grupo de registros eliminado cuando se utilizan registros de auditoría
Si el grupo de registros no existe, el usuario puede seleccionar el enlace del grupo de registros que aparece debajo de ese mensaje para crear un nuevo grupo de registros o usar un grupo de registros existente para usarlo como destino de los registros de auditoría
No puede cargar archivos en su bucket de S3
Si no puede cargar archivos en su bucket de S3, haga lo siguiente:
-
Asegúrese de haber concedido el acceso necesario a Amazon S3 File Gateway para cargar archivos en su bucket de S3. Para obtener más información, consulte Concesión de acceso a un bucket de Amazon S3.
-
Asegúrese de que el rol que creó el bucket tenga permiso para escribir en el bucket de S3. Para obtener más información, consulte las prácticas recomendadas para File Gateway.
-
Si su puerta de enlace de archivos utiliza SSE-KMS o DSSE-KMS para el cifrado, asegúrese de que la función de IAM asociada al recurso compartido de archivos incluya los permisos KMS:Encrypt, KMS:Decrypt, kms: *, kms: y kms:. ReEncrypt GenerateDataKey DescribeKey Para obtener más información, consulte Uso de políticas basadas en la identidad (políticas de IAM) para Storage Gateway.
No puedo cambiar el cifrado predeterminado para usar SSE-KMS para cifrar los objetos almacenados en mi bucket de S3
Si cambia el cifrado predeterminado y establece el SSE-KMS (cifrado del lado del servidor con claves AWS KMS administradas) como el predeterminado para su bucket de S3, los objetos que Amazon S3 File Gateway almacena en el bucket no se cifran con SSE-KMS. De forma predeterminada, una puerta de enlace de archivos de S3 utiliza el cifrado del lado del servidor gestionado con Amazon S3 (SSE-S3) cuando escribe datos en un bucket de S3. Cambiar la configuración predeterminada no cambiará el cifrado automáticamente.
Para cambiar el cifrado y usar SSE-KMS con su propia AWS KMS clave, debe activar el cifrado SSE-KMS. Para ello, debe proporcionar el nombre de recurso de Amazon (ARN) de la clave de KMS al crear el recurso compartido de archivos. También puede actualizar la configuración de KMS para el recurso compartido de archivos utilizando operación UpdateNFSFileShare
o UpdateSMBFileShare
de la API. Esta actualización se aplica a los objetos almacenados en los buckets de S3 después de la actualización. Para obtener más información, consulte Cifrado de datos mediante AWS KMS.
Los cambios realizados directamente en un bucket de S3 con el control de versiones de objetos activado pueden afectar a lo que veas en tu recurso compartido de archivos
Si su bucket de S3 tiene objetos escritos en él por otro cliente, es up-to-date posible que su visión del bucket de S3 no se deba al control de versiones de los objetos del bucket de S3. Actualice siempre la caché antes de examinar los archivos que le interesen.
El control de versiones de objetos es una característica opcional del bucket de S3 que ayuda a proteger los datos al almacenar varias copias del objeto con el mismo nombre. Cada copia tiene un valor de ID independiente, por ejemplo file1.jpg
: ID="xxx"
y file1.jpg
: ID="yyy"
. La cantidad de objetos con nombres idénticos y su vida útil se controlan mediante las políticas de ciclo de vida de Amazon S3. Para obtener más información sobre estos conceptos de Amazon S3, consulte Uso del control de versiones y la gestión del ciclo de vida de los objetos en la Guía para desarrolladores de Amazon S3.
Cuando se elimina un objeto con control de versiones, ese objeto se marca con un marcador de eliminación pero se conserva. Solo el propietario de un bucket de S3 puede eliminar definitivamente un objeto con el control de versiones activado.
En su puerta de enlace de archivos de S3, los archivos que se muestran son las versiones más recientes de los objetos de un bucket de S3 en el momento en que se obtuvo el objeto o se actualizó la caché. Las pasarelas de archivos de S3 ignoran las versiones anteriores o los objetos marcados para su eliminación. Cuando se lee un archivo, los datos que se leen son de la versión más reciente. Al escribir un archivo en su recurso compartido de archivos, su S3 File Gateway crea una nueva versión de un objeto con nombre asignado con los cambios y esa versión pasa a ser la última versión.
Su puerta de enlace de archivos de S3 sigue leyendo la versión anterior y las actualizaciones que realice se basan en la versión anterior en caso de que se añada una nueva versión al bucket de S3 fuera de su aplicación. Para leer la versión más reciente de un objeto, utilice la acción de la RefreshCacheAPI o actualice desde la consola, tal y como se describe enActualización de la caché de objetos del bucket de Amazon S3.
importante
No recomendamos que los objetos o archivos se escriban en el bucket S3 de S3 de S3 de S3 desde fuera del recurso compartido de archivos.
Al escribir en un bucket de S3 con el control de versiones activado, Amazon S3 File Gateway puede crear varias versiones de los objetos de Amazon S3
Con el control de versiones de objetos activado, es posible que cree varias versiones de un objeto en Amazon S3 en cada actualización de un archivo desde su cliente NFS o SMB. Estos son algunos escenarios que pueden provocar la creación de varias versiones de un objeto en su bucket de S3:
-
Cuando un cliente NFS o SMB modifica un archivo en Amazon S3 File Gateway después de cargarlo en Amazon S3, S3 File Gateway carga los datos nuevos o modificados en lugar de cargar todo el archivo. La modificación del archivo da como resultado la creación de una nueva versión del objeto Amazon S3.
-
Cuando un cliente NFS o SMB escribe un archivo en S3 File Gateway, S3 File Gateway carga los datos del archivo en Amazon S3 seguidos de sus metadatos (propietarios, marcas de tiempo, etc.). Al cargar los datos del archivo, se crea un objeto de Amazon S3 y, al cargar los metadatos del archivo, se actualizan los metadatos del objeto de Amazon S3. Este proceso crea otra versión del objeto, lo que da como resultado dos versiones de un objeto.
-
Cuando la puerta de enlace de archivos de S3 carga archivos más grandes, es posible que tenga que cargar partes más pequeñas del archivo antes de que el cliente termine de escribir en la puerta de enlace de archivos. Esto se debe, entre otras razones, a liberar espacio en la memoria caché o a una alta tasa de escrituras en un archivo. Esto puede provocar varias versiones de un objeto en el bucket de S3.
Debe supervisar su depósito de S3 para determinar cuántas versiones de un objeto existen antes de configurar políticas de ciclo de vida para mover los objetos a diferentes clases de almacenamiento. Debe configurar la caducidad del ciclo de vida de las versiones anteriores a fin de minimizar la cantidad de versiones que tiene para un objeto en su depósito de S3. El uso de la replicación en la misma región (SRR) o la replicación entre regiones (CRR) entre depósitos de S3 aumentará el almacenamiento utilizado. Para obtener más información sobre la replicación, consulte Replicación.
importante
No configure la replicación entre depósitos de S3 hasta que sepa cuánto almacenamiento se utiliza cuando se activa el control de versiones de los objetos.
El uso de buckets S3 versionados puede aumentar considerablemente la cantidad de almacenamiento en Amazon S3, ya que cada modificación de un archivo crea una nueva versión del objeto S3. De forma predeterminada, Amazon S3 sigue almacenando todas estas versiones a menos que cree específicamente una política para anular este comportamiento y limitar el número de versiones que se conservan. Si observa un uso de almacenamiento inusualmente elevado con el control de versiones de objetos activado, compruebe que sus políticas de almacenamiento estén configuradas de forma adecuada. Un aumento en el número de respuestas HTTP 503-slow down
a las solicitudes del navegador también puede indicar la existencia de problemas con el control de versiones de objetos.
Si activa el control de versiones de objetos después de instalar una puerta de enlace de archivos de S3, se conservan todos los objetos únicos (ID=”NULL”
) y podrá verlos todos en el sistema de archivos. A las versiones nuevas de los objetos se les asigna un ID exclusivo (las versiones anteriores se conservan). Basándose en la marca temporal del objeto, solo se puede ver el objeto con control de versiones más reciente en el sistema de archivos de NFS.
Tras activar el control de versiones de objetos, el bucket de S3 no podrá volver a un estado no versionado. Sin embargo, sí que se puede suspender el control de versiones. Al suspender el control de versiones, a los objetos nuevos se les asigna un ID. Si el objeto con el mismo nombre existe con un valor ID=”NULL”
, la versión anterior se sobrescribe. Sin embargo, las versiones que contengan ID que no sean NULL
se conservan. Las marcas temporales identifican el objeto nuevo como el objeto actual y ese el que aparece en el sistema de archivos de NFS.
Los cambios en un bucket de S3 no se reflejan en Storage Gateway
Storage Gateway actualiza la caché del recurso compartido de archivos automáticamente cuando se escriben archivos en la caché de forma local mediante el recurso compartido de archivos. Sin embargo, Storage Gateway no actualiza automáticamente la memoria caché cuando se carga un archivo directamente en Amazon S3. Al hacerlo, debe realizar una RefreshCache
operación para ver los cambios en el recurso compartido de archivos. Si tiene más de un recurso compartido de archivos, debe ejecutar la RefreshCache
operación en cada recurso compartido de archivos.
Puede actualizar la memoria caché mediante la consola Storage Gateway y AWS Command Line Interface (AWS CLI):
-
Para actualizar la caché mediante la consola Storage Gateway, consulte Refrescar objetos en su bucket de Amazon S3.
-
Para actualizar la memoria caché mediante AWS CLI:
-
Ejecute el comando
aws storagegateway list-file-shares
-
Copie el número de recurso de Amazon (ARN) del recurso compartido de archivos con la caché que desee actualizar.
-
Ejecute el
refresh-cache
comando con su ARN como valor para:--file-share-arn
aws storagegateway refresh-cache --file-share-arn arn:aws:storagegateway:eu-west-1:12345678910:share/share-FFDEE12
-
Para automatizar la RefreshCache
operación, consulte ¿Cómo puedo automatizar la RefreshCache operación en Storage Gateway?
Los permisos de ACL no funcionan como se esperaba
Si los permisos de lista de control de acceso (ACL) no funcionan según lo previsto en un recurso compartido de archivos SMB, puede hacer una prueba.
Para ello, en primer lugar, pruebe los permisos en un servidor de archivos de Microsoft Windows o un recurso compartido de archivos de Windows local. A continuación, compare el comportamiento con el del recurso compartido de archivos de la gateway.
El rendimiento de su puerta de enlace disminuyó después de realizar una operación recursiva
En algunos casos, puede realizar una operación recursiva, como cambiar el nombre de un directorio o activar la herencia de una ACL, y forzarla a descender en el árbol. Si lo hace, la puerta de enlace de archivos de S3 aplicará la operación de forma recursiva a todos los objetos del recurso compartido de archivos.
Por ejemplo, supongamos que aplica la herencia a los objetos existentes en un bucket de S3. Su S3 File Gateway aplica la herencia de forma recursiva a todos los objetos del depósito. Este tipo de operaciones pueden provocar la degradación del rendimiento de la gateway.