ECS: Errores de I/O remotos de NFS; el cambio del propietario del depósito por un depósito activado por FS puede provocar que las aplicaciones o los usuarios no puedan acceder a los archivos de NFS
Summary: El propietario del depósito anterior no está permitido o restringido ObjectControllerException: Método updateObjectInternal no permitido para el propietario del depósito anterior
This article applies to
This article does not apply to
Symptoms
Cambio realizado por el usuario a la página del propietario del depósito en la interfaz del usuario:
Este problema se aplica a los depósitos habilitados para NFS y a un cambio del propietario del depósito por parte de la interfaz del usuario. Esto puede provocar que las aplicaciones o los usuarios conectados pierdan el acceso al depósito en el sistema de archivos Linux. Incluso si volvemos a revertir el cambio al propietario original, el acceso no será posible para la DU.
En este ejemplo:
el propietario del depósito se cambió a "bucket2" mediante la interfaz del usuario. Debido a una limitación en ECS, incluso después de volver a cambiar el nombre del propietario del depósito a "pool1". ECS no cambiará el propietario del depósito a "bucket1" mediante la interfaz del usuario. Esto solo se puede hacer por ahora con la CLI mediante una API con carga útil para restablecer la marca de propietario a true.
Formas de identificar el problema, en la máquina con Linux, solicite al usuario que toque un archivo, por ejemplo:
Este problema se aplica a los depósitos habilitados para NFS y a un cambio del propietario del depósito por parte de la interfaz del usuario. Esto puede provocar que las aplicaciones o los usuarios conectados pierdan el acceso al depósito en el sistema de archivos Linux. Incluso si volvemos a revertir el cambio al propietario original, el acceso no será posible para la DU.
En este ejemplo:
el propietario del depósito se cambió a "bucket2" mediante la interfaz del usuario. Debido a una limitación en ECS, incluso después de volver a cambiar el nombre del propietario del depósito a "pool1". ECS no cambiará el propietario del depósito a "bucket1" mediante la interfaz del usuario. Esto solo se puede hacer por ahora con la CLI mediante una API con carga útil para restablecer la marca de propietario a true.
Formas de identificar el problema, en la máquina con Linux, solicite al usuario que toque un archivo, por ejemplo:
admin@node1~>touch file
touch: setting times of `file': Remote I/O error
se svc_log with the string "method updateObjectInternal "
Command:
# svc_log -a -sr dataheadsvc | grep "method updateObjectInternal"
Example:
admin@node1~>svc_log -a -sr dataheadsvc | grep "method updateObjectInternal" svc_log v1.0.22 (svc_tools v1.5.3) Started 2019-06-06 10:45:04 Running on nodes: <All nodes> Time range: 2019-06-05 10:45:04 - 2019-06-06 10:45:04 Filter string(s): <All messages> Show nodename(s): True Search reclaim logs (if any): False com.emc.storageos.data.object.exception.ObjectControllerException: method updateObjectInternal not allowed for previous bucket owner sham1 Caused by: com.emc.storageos.data.object.exception.ObjectControllerException: method updateObjectInternal not allowed for previous bucket owner sham1
Cause
Creación de un depósito con un usuario específico como propietario, seguido de un cambio en la propiedad del depósito. Por último, si se le otorga al propietario original el control total mediante la página ACL, se produce un error con la excepción de registro de ECS:
ObjectControllerException: method updateObjectInternal not allowed for previous bucket owner <ownerid> This is a known issue currently being evaluated by Dell EMC at this time.
Resolution
La solución alternativa es cambiar el propietario del depósito mediante la API a través de la CLI con la carga útil para restablecer la marca de propietario a true.
1. Determine el propietario actual del depósito.
2. Cree un archivo xml simple mediante el editor vi. En el siguiente ejemplo, se denomina /tmp/bucket-owner.xml. Este es un proceso de dos pasos. Tenemos que establecerlo en un nuevo propietario temporalmente de xxxx 2. Como en este ejemplo a continuación, antes de volver a establecer en el propietario original, debe confirmar la salida:
. 7. Una vez que se haya realizado el cambio de configuración, ya no se debería ver el mismo error
1. Determine el propietario actual del depósito.
Requiere la contraseña raíz de la interfaz de usuario para generar el TOKEN. Por ejemplo:
admin@ecsnode1:~> tok=$(curl -iks https://XX.XX.XX.XX:4443/login -u 'root:ChangeMe' | grep X-SDS-AUTH-TOKEN)
Verifique el propietario actual del depósito (sustituya el depósito y el espacio de nombres en su situación):
admin@node1:~> curl -s -k -X GET -H "$tok" https://XX.XX.XX.XX:4443/object/bucket/sham_bk_nfs/info?namespace=degreat_nfs | xmllint --format - | grep '<owner>' <owner>sham2</owner>
Esto confirma que es necesario establecer el parámetro reset_previous_owners en true. El propietario del depósito revertido se encuentra en la interfaz del usuario, pero la API a través de la CLI confirma que ECS sigue viendo al propietario del depósito como "bucket2".
2. Cree un archivo xml simple mediante el editor vi. En el siguiente ejemplo, se denomina /tmp/bucket-owner.xml. Este es un proceso de dos pasos. Tenemos que establecerlo en un nuevo propietario temporalmente de xxxx 2. Como en este ejemplo a continuación, antes de volver a establecer en el propietario original, debe confirmar la salida:
admin@node1:~ # vi /tmp/bucket-owner.xml admin@ecsnode1:~ # cat /tmp/bucket-owner.xml <object_bucket_update_owner> <namespace>degreat_nfs</namespace> <new_owner>sham2</new_owner> <reset_previous_owners>true</reset_previous_owners> </object_bucket_update_owner> 3. Change the bucket owner to the temporary owner.
La sintaxis de la API necesaria para cambiar el propietario del depósito a "bucket2" a través del archivo xml es la siguiente:
admin@ecsnode1:~> curl -v -k -X "POST" "https://xx.xx.xx.xx:4443/object/bucket/sham_bk_nfs/owner" -H "$tok" -H "Content-Type: application/xml" -H "ACCEPT:application/xml" -d @/tmp/bucket-owner.xml -v * Hostname was NOT found in DNS cache * Trying xx.xx.xx.xx... * Connected to xx.xx.xx.xx (xx.xx.xx.xx) port 4443 (#0) * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs/ * SSLv3, TLS unknown, Certificate Status (22): * SSLv3, TLS handshake, Client hello (1): * SSLv3, TLS handshake, Server hello (2): * SSLv3, TLS handshake, Certificate (11): * SSLv3, TLS handshake, Server key exchange (12): * SSLv3, TLS handshake, Server finished (14): * SSLv3, TLS handshake, Client key exchange (16): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 * Server certificate: * subject: CN=localhost * start date: 2019-03-25 09:53:41 GMT * expire date: 2029-03-22 09:53:41 GMT * issuer: CN=localhost * SSL certificate verify result: self signed certificate (18), continuing anyway. > POST /object/bucket/sham_bk_nfs/owner HTTP/1.1 > User-Agent: curl/7.37.0 > Host: xx.xx.xx.xx:4443 > X-SDS-AUTH-TOKEN: BAAcUy9KYlhxTlVYb2M0bnF3bTNscEsvSEdDeWhJPQMAjAQASHVybjpzdG9yYWdlb3M6VmlydHVhbERhdGFDZW50ZXJEYXRhOmJhOGQ3ZTkzLTMyMGYtNDNmNy05Y2FkLWM4YWQzMWFiMzY1MAIADTE1NTk3Mzk3OTA2MDgDAC51cm46VG9rZW46YjQ4NGNiZjEtNTkwNy00YWI3LTgzYTctM2Y3OGRhM2RiY2NiAgAC0A8= > Content-Type: application/xml > ACCEPT:application/xml > Content-Length: 179 > * upload completely sent off: 179 out of 179 bytes < HTTP/1.1 200 OK < Date: Thu, 06 Jun 2019 10:56:08 GMT < Content-Length: 0 < Connection: keep-alive < * Connection #0 to host xx.xx.xx.xx left intact 4. Edit the simple.xml file previously created in step 2 and this time insert original owner of sham1
admin@node1:~ # vi /tmp/bucket-owner.xml admin@ecsnode1:~ # cat /tmp/bucket-owner.xml <object_bucket_update_owner> <namespace>degreat_nfs</namespace> <new_owner>sham1</new_owner> <reset_previous_owners>true</reset_previous_owners> </object_bucket_update_owner> 5. Change the bucket owner back to the original owner The API syntax required to change the bucket owner back to "sham1" through the xml file is as follows:
admin@ecsnode1:~> curl -v -k -X "POST" "https://xx.xx.xx.xx:4443/object/bucket/sham_bk_nfs/owner" -H "$tok" -H "Content-Type: application/xml" -H "ACCEPT:application/xml" -d @/tmp/bucket-owner.xml -v * Hostname was NOT found in DNS cache * Trying xx.xx.xx.xx... * Connected to xx.xx.xx.xx (xx.xx.xx.xx) port 4443 (#0) * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs/ * SSLv3, TLS unknown, Certificate Status (22): * SSLv3, TLS handshake, Client hello (1): * SSLv3, TLS handshake, Server hello (2): * SSLv3, TLS handshake, Certificate (11): * SSLv3, TLS handshake, Server key exchange (12): * SSLv3, TLS handshake, Server finished (14): * SSLv3, TLS handshake, Client key exchange (16): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 * Server certificate: * subject: CN=localhost * start date: 2019-03-25 09:53:41 GMT * expire date: 2029-03-22 09:53:41 GMT * issuer: CN=localhost * SSL certificate verify result: self signed certificate (18), continuing anyway. > POST /object/bucket/sham_bk_nfs/owner HTTP/1.1 > User-Agent: curl/7.37.0 > Host: xx.xx.xx.xx:4443 > X-SDS-AUTH-TOKEN: BAAcUy9KYlhxTlVYb2M0bnF3bTNscEsvSEdDeWhJPQMAjAQASHVybjpzdG9yYWdlb3M6VmlydHVhbERhdGFDZW50ZXJEYXRhOmJhOGQ3ZTkzLTMyMGYtNDNmNy05Y2FkLWM4YWQzMWFiMzY1MAIADTE1NTk3Mzk3OTA2MDgDAC51cm46VG9rZW46YjQ4NGNiZjEtNTkwNy00YWI3LTgzYTctM2Y3OGRhM2RiY2NiAgAC0A8= > Content-Type: application/xml > ACCEPT:application/xml > Content-Length: 179 > * upload completely sent off: 179 out of 179 bytes < HTTP/1.1 200 OK < Date: Thu, 06 Jun 2019 10:56:08 GMT < Content-Length: 0 < Connection: keep-alive < * Connection #0 to host xx.xx.xx.xx left intact 6. Confirm the bucket owner change is reflected.
Confirme que el cambio del propietario del depósito ahora sea "bucket1".
admin@ecsnode1:~> curl -s -k -X GET -H "$tok" https://XX.XX.XX.XX:4443/object/bucket/sham_bk_nfs/info?namespace=degreat_nfs | xmllint --format - | grep '<owner>' <owner>sham1</owner>
Una vez que se revierta el propietario del depósito en la API, confirme que el host ahora pueda acceder al depósito en el sistema de archivos linux.
. 7. Una vez que se haya realizado el cambio de configuración, ya no se debería ver el mismo error
svc_log -f "method updateObjectInternal not allowed" -start "20 hour ago" -sr all -sh -st hour svc_log v1.0.22 (svc_tools v1.6.8) Started 2020-01-23 09:28:17 Running on nodes: <All nodes> Time range: 2020-01-22 13:28:17 - 2020-01-23 09:28:17 Filter string(s): 'method updateObjectInternal not allowed' Show nodename(s): True Search reclaim logs (if any): False Count of message occurrences per hour: 2020-01-22 13:xx - 5066 2020-01-22 14:xx - 9580 2020-01-22 15:xx - 9574 2020-01-22 16:xx - 9580 2020-01-22 17:xx - 9570 2020-01-22 18:xx - 9576 2020-01-22 19:xx - 9564 2020-01-22 20:xx - 9576 2020-01-22 21:xx - 9576 2020-01-22 22:xx - 9572 2020-01-22 23:xx - 9564 2020-01-23 00:xx - 9586 2020-01-23 01:xx - 9574 2020-01-23 02:xx - 9572 2020-01-23 03:xx - 4564 2020-01-23 04:xx - 0 2020-01-23 05:xx - 0 2020-01-23 06:xx - 0 2020-01-23 07:xx - 0 2020-01-23 08:xx - 0 2020-01-23 09:xx - 0 Dell EMC is aware of this issue and are working on a fix in a future release.
Additional Information
Base de conocimientos de NFS relacionado:
Puede suscribirse a las actualizaciones siguiendo las instrucciones que se indican en el siguiente artículo de la base de conocimientos:
DELL EMC: ¿Cómo suscribirse a las páginas de productos: soporte de Dell?
- ECS: Cómo crear una exportación básica de NFS y montarla en un cliente
- ECS: NFS no puede escribir ni eliminar objetos
- ECS: Las escrituras extensas de NFS desde ESXi pueden fallar después de la actualización a 3.2
- ECS: Restablecimiento de la configuración de exportación de NFS después de agregar una nueva exportación en un entorno de múltiples V CC
- ECS: error de streaming de registros de dataheadsvc: ENLACE del procedimiento de NFSv3 no soportado en la solicitud ReadLinkRequest
- ECS: Error de duplicación de cookies cuando se muestra NFS
- ECS: En el montaje de NFS, se indica No such file or directory o ERROR_OBJECT_NOT_FOUND
- ECS: Una lista de archivos del depósito de NFS que contenga más de 2 millones de archivos puede estar lenta o fallar
- ECS: La máquina NFS Client/Linux no enumera la subcarpeta o directorio creado mediante el navegador S3, pero el contenido de la subcarpeta aparece en el directorio principal o raíz
- ECS: Error de I/O remoto recibido cuando se intentaba escribir en un depósito con NFS
- ECS: Errores de I/O remotos de NFS; El cambio del propietario del depósito para el depósito habilitado para FS puede provocar que las aplicaciones o los usuarios no puedan acceder a los archivos NFS
- ECS: La escritura de NFS indica un error de I/O después de una cierta cantidad de datos.
- ECS: Uso del recurso compartido de archivos NFS de ECS con un almacén de datos NFS de VMware
- ECS: Prácticas recomendadas para el montaje de exportaciones de NFS de ECS
- ECS: Cómo montar un recurso compartido de NFS en un cliente de Windows
- ECS: NFS no se puede montar después de cambiar los ajustes de exportación de archivos en la IU
- ECS: ¿Oracle WebCenter Content (WCC) es compatible con ECS?
Puede suscribirse a las actualizaciones siguiendo las instrucciones que se indican en el siguiente artículo de la base de conocimientos:
DELL EMC: ¿Cómo suscribirse a las páginas de productos: soporte de Dell?