ЕКС: помилки віддаленого вводу/виводу NFS; Зміна власника сегмента для сегмента з увімкненою FS може призвести до того, що програми та/або користувачі не зможуть отримати доступ до файлів NFS
Summary: Попередній власник сегмента не дозволений або обмежений ObjectControllerException: Метод updateObjectInternal заборонено для попереднього власника сегмента
This article applies to
This article does not apply to
This article is not tied to any specific product.
Not all product versions are identified in this article.
Symptoms
Зміна, внесена користувачем на сторінці власника сегмента в інтерфейсі користувача:
Ця проблема стосується сегментів із підтримкою NFS і зміни власника сегмента в інтерфейсі користувача. Це може призвести до того, що програми або підключені користувачі втратять доступ до сегмента у файловій системі Linux. Навіть якщо ми знову повернемо зміну до початкового власника, доступ буде неможливим, що призведе до DU.
У цьому прикладі:
Власника сегмента змінено на "sham2" за допомогою інтерфейсу користувача. Через обмеження в ECS, навіть після зміни імені власника сегмента назад на "sham1". ECS не змінює власника сегмента назад на "sham1" за допомогою інтерфейсу користувача. Поки що це можна зробити лише за допомогою командного рядка за допомогою API з корисним навантаженням для скидання прапорця власника на true.
Способи виявлення проблеми, на комп'ютері з Linux попросіть користувача торкнутися файлу, наприклад:
Ця проблема стосується сегментів із підтримкою NFS і зміни власника сегмента в інтерфейсі користувача. Це може призвести до того, що програми або підключені користувачі втратять доступ до сегмента у файловій системі Linux. Навіть якщо ми знову повернемо зміну до початкового власника, доступ буде неможливим, що призведе до DU.
У цьому прикладі:
Власника сегмента змінено на "sham2" за допомогою інтерфейсу користувача. Через обмеження в ECS, навіть після зміни імені власника сегмента назад на "sham1". ECS не змінює власника сегмента назад на "sham1" за допомогою інтерфейсу користувача. Поки що це можна зробити лише за допомогою командного рядка за допомогою API з корисним навантаженням для скидання прапорця власника на true.
Способи виявлення проблеми, на комп'ютері з Linux попросіть користувача торкнутися файлу, наприклад:
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
Створення сегмента з певним користувачем як власником із подальшою зміною власника сегмента. Нарешті, надання початковому власнику повного контролю за допомогою сторінки ACL зазнає невдачі за винятком журналу 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
Обхідний шлях полягає в тому, щоб змінити власника сегмента за допомогою API через CLI з корисним навантаженням, щоб скинути прапорець власника на true.
1. Визначте поточного власника ковша.
2. Створіть простий xml-файл за допомогою редактора vi. У наведеному нижче прикладі він називається /tmp/bucket-owner.xml. Це двоетапний процес. Ми повинні встановити його новому власнику sham2. Як у наведеному нижче прикладі, перед встановленням початкового власника sham1 підтвердьте виведені дані:
. 7. Після того, як зміна конфігурації буде завершена, ми більше не повинні бачити ту саму помилку
1. Визначте поточного власника ковша.
Вимагати пароль користувача root для створення ТОКЕНА. Наприклад:
admin@ecsnode1:~> tok=$(curl -iks https://XX.XX.XX.XX:4443/login -u 'root:ChangeMe' | grep X-SDS-AUTH-TOKEN)
Перевірте поточного власника сегмента (замініть сегмент і простір імен у вашій ситуації).
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>
Це підтверджує параметр reset_previous_owners має бути встановлено значення true. Скасований власник сегмента відображається в інтерфейсі користувача, але API через CLI підтверджує, що ECS все ще бачить власника сегмента як "sham2".
2. Створіть простий xml-файл за допомогою редактора vi. У наведеному нижче прикладі він називається /tmp/bucket-owner.xml. Це двоетапний процес. Ми повинні встановити його новому власнику sham2. Як у наведеному нижче прикладі, перед встановленням початкового власника 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>sham2</new_owner> <reset_previous_owners>true</reset_previous_owners> </object_bucket_update_owner> 3. Change the bucket owner to the temporary owner.
Синтаксис API, необхідний для зміни власника сегмента на "sham2" через xml-файл, виглядає наступним чином:
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.
Підтвердьте, що зміна власника відра тепер "sham1".
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>
Після того, як власника сегмента буде відновлено в API, переконайтеся, що хост тепер може отримати доступ до сегмента у файловій системі Linux.
. 7. Після того, як зміна конфігурації буде завершена, ми більше не повинні бачити ту саму помилку
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
Пов'язані КБ НФС:
Ви можете підписатися на оновлення, дотримуючись інструкцій у статті знань нижче:DELL EMC:
Як підписатися на сторінки продуктів - служба підтримки Dell?
- ЕКС: Як створити базовий експорт NFS і змонтувати його на клієнті
- ЕКС: NFS не може записувати або видаляти об'єкти
- ЕКС: Великі записи NFS з ESXi можуть виходити з ладу після оновлення 3.2
- ЕКС: Скидання конфігурації експорту NFS після додавання нового експорту в середовищі Multi-VDC
- ECS: помилка потокової передачі журналу dataheadsvc: Процедура NFSv3 LINK не підтримується в запиті ReadLinkRequest
- ЕКС: Помилка дублювання файлів cookie при лістингу NFS
- ЕКС: Помилка монтування NFS з відсутністю такого файлу, каталогу або ERROR_OBJECT_NOT_FOUND
- ЕКС: Список файлів сегмента NFS, що містить понад 2 мільйони файлів, може працювати повільно або не працювати
- ЕКС: Підпапка або каталог, створені за допомогою браузера S3, не відображаються клієнтом NFS або комп'ютером Linux, але вміст підпапки відображається в основному або кореневому каталозі
- ЕКС: Помилка віддаленого вводу/виводу, отримана під час спроби записати в сегмент із NFS
- ЕКС: помилки віддаленого вводу/виводу NFS; Зміна власника сегмента для сегмента з увімкненою FS може призвести до того, що програми/користувачі не зможуть отримати доступ до файлів NFS
- ЕКС: Запис NFS видає помилку введення-виведення після певної кількості даних.
- ЕКС: Використання спільного доступу до файлів NFS з ECS зі сховищем даних VMware NFS
- ЕКС: Практичні поради щодо монтажу експорту ECS NFS
- ЕКС: Як підключити спільний доступ NFS у клієнті Windows
- ЕКС: NFS не монтується після зміни параметрів експорту файлів в інтерфейсі користувача
- ЕКС: Чи сумісний Oracle WebCenter Content (WCC) з ECS?
Ви можете підписатися на оновлення, дотримуючись інструкцій у статті знань нижче:DELL EMC:
Як підписатися на сторінки продуктів - служба підтримки Dell?
Affected Products
Elastic Cloud StorageProducts
ECS Appliance, ECS Appliance Software with Encryption, ECS Appliance Software without Encryption, Elastic Cloud StorageArticle Properties
Article Number: 000055535
Article Type: Solution
Last Modified: 25 Mar 2025
Version: 4
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.