Skip to main content
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Enjoy members-only rewards and discounts
  • Create and access a list of your products

ЕКС: помилки віддаленого вводу/виводу NFS; Зміна власника сегмента для сегмента з увімкненою FS може призвести до того, що програми та/або користувачі не зможуть отримати доступ до файлів NFS

Summary: Попередній власник сегмента не дозволений або обмежений ObjectControllerException: Метод updateObjectInternal заборонено для попереднього власника сегмента

This article applies to   This article does not apply to 

Symptoms

Зміна, внесена користувачем на сторінці власника сегмента в інтерфейсі користувача:
kA23a0000000BOMCA2_3_0

Ця проблема стосується сегментів із підтримкою 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. Визначте поточного власника ковша.
Вимагати пароль користувача 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?

Affected Products

Elastic Cloud Storage

Products

ECS Appliance, ECS Appliance Software with Encryption, ECS Appliance Software without Encryption, Elastic Cloud Storage