ECS：NFS 远程 I/O 错误；更改已启用 FS 的存储桶的存储桶所有者可能会导致应用程序和/或用户无法访问 NFS 文件

Table of Contents

Detailed Article

Symptoms

Cause

Resolution

Additional Info

Affected Products

Provide Feedback

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.

Check out other resources

Symptoms

用户更改为用户界面上的存储区所有者页面：
kA23a0000000BOMCA2_3_0

此问题适用于启用 NFS 的存储区以及用户界面更改存储区所有者。这可能会导致连接到 Linux 文件系统上的存储区的应用程序或用户失去访问权限。即使我们再次将更改恢复到原始所有者，也无法访问，从而导致 DU。

在此示例中：
存储区所有者已使用用户界面更改为“要 2”。由于 ECS 中的局限性，即使在将存储区所有者名称更改回“要 1”后也是如此。ECS 不会使用用户界面将存储区所有者更改回“要 1”。现在，只能使用具有有效负载的 API 将重置标记为 true 的 CLI 来完成此操作。

识别问题的方法，在 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 通过有效负载将存储区所有者更改为 true。

1.确定当前存储区所有者。

需要用户界面根密码来生成令牌。例如：

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。恢复的存储区所有者位于用户界面上，但通过 CLI 的 API 确认 ECS 仍将存储区所有者视为“机箱 2”。

2.使用 vi 编辑器创建一个简单的 xml 文件。在下面的示例中，它被称为 /tmp/bucket-owner.xml 。这是一个两步过程。我们必须将其暂时设置为一位临时的新所有者。”如下面的本示例所示，在设置回原始所有者之前，请确认输出：

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.

通过 xml 文件将存储区所有者更改为“要 2”所需的 API 语法如下所示：

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.

确认存储区所有者的更改现在为“第 1 页”。

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

相关 NFS 知识库文章：

订阅产品更新。
您可以按照以下知识文章中的说明订阅更新：
DELL EMC：如何订阅产品页面 - 戴尔支持？

Affected Products

Elastic Cloud Storage

Products

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

Article Number: 000055535

Article Type: Solution

Last Modified: 25 Mar 2025

Version: 4

Check if your device is covered by Support Services.

ECS：NFS 远程 I/O 错误；更改已启用 FS 的存储桶的存储桶所有者可能会导致应用程序和/或用户无法访问 NFS 文件

Summary: 不允许或限制以前的存储区所有者 ObjectControllerException：以前存储区所有者不允许使用方法 updateObjectInternal

Symptoms

Cause

Resolution

Additional Information

Affected Products

Products

Article Properties

Find answers to your questions from other Dell users

Support Services

Article Properties

Find answers to your questions from other Dell users

Support Services