ossfs 1.0用戶端異常問題排查 - Container Service for Kubernetes

OSS儲存卷是通過ossfs掛載的FUSE檔案系統。您可以通過分析Debug日誌或查詢Pod日誌的方式來排查ossfs的異常問題。本文劃分了常見的ossfs異常問題，並通過樣本介紹了ossfs通用的排查方法。

排查說明

CSI儲存外掛程式版本	ossfs運行方式	異常問題的排查方式
v1.28之前版本	ossfs以後台形式運行在業務Pod所在的節點上，運行異常時需要重新以前台方式掛載。	分析Debug日誌
v1.28及之後，v1.30.4之前	ossfs以容器形式運行在`kube-system`命名空間下的Pod中。	查詢Pod日誌
v1.30.4及之後	ossfs以容器形式運行在`ack-csi-fuse`命名空間下的Pod中。	查詢Pod日誌

重要

為避免ossfs運行時產生大量日誌，容器方式運行時預設的日誌等級為critical或error。在進行Debug排查時，可能需要增加Debug參數並重新掛載。

適用情境1：掛載失敗

OSS靜態卷掛載失敗，Pod無法啟動，Event提示FailedMount時，請優先參見OSS儲存卷掛載失敗，業務Pod Event提示FailedMount進行快速排查。

CSI Plugin組件為1.26.6及之後的版本

問題現象

業務Pod啟動時，長期處於ContainerCreating狀態。

問題原因

請先確認ossfs容器是否正常運行。若ossfs容器運行正常，請排查是否由於節點異常等原因導致業務Pod處於ContainerCreating狀態。

說明

命令中的<NODE_NAME>指異常業務Pod所在的節點名稱。
命令中的<VOLUME_ID>一般指實際業務PV的名稱，以下兩種情境需要重新擷取該值：
- PV名稱與PV的volumeHandle欄位的值不同時，需要使用volumeHandle欄位。可使用以下指令擷取某個PV的volumeHandle值：
```
kubectl get pv <PV_NAME> -o jsonpath='{.spec.csi.volumeHandle}'
```
- PV名稱過長時，<VOLUME_ID>由"h1."與其sha1值拼接得到。可使用以下指令擷取該值：
```
echo -n "<PV_NAME>" | sha1sum | sed 's/^/h1./'
```
  若系統不支援sha1sum操作，也可使用openSSL庫擷取該值：
```
echo -n "<PV_NAME>" | openssl sha1 -binary | xxd -p -c 40 | sed 's/^/h1./'
```

CSI版本為v1.30.4及之後

kubectl -n ack-csi-fuse get pod -l csi.alibabacloud.com/volume-id=<VOLUME_ID> -o wide | grep <NODE_NAME>

由於該版本ossfs容器中新增守護進程，無論ossfs進程是否正常運行，預期輸出均為：

NAME                   READY   STATUS             RESTARTS     AGE
csi-fuse-ossfs-xxxx    1/1     Running            0            5s

若ossfs容器處於非Running狀態，請先排查異常原因。

CSI版本為1.30.4之前

kubectl -n kube-system get pod -l csi.alibabacloud.com/volume-id=<VOLUME_ID> -o wide | grep <NODE_NAME>

若ossfs容器運行異常，則預期輸出為：

NAME                   READY   STATUS             RESTARTS     AGE
csi-fuse-ossfs-xxxx    0/1     CrashLoopBackOff   1 (4s ago)   5s

出現此類事件的原因：CSI組件在拉起ossfs容器時，ossfs異常退出。OSS連通性檢查出錯（例如Bucket不存在和許可權配置錯誤等）、OSS掛載路徑不存在、無讀寫權限等初始化檢查的錯誤均可能導致此問題。

解決方案

查詢ossfs容器日誌。
- CSI版本為v1.30.4及之後
```
kubectl -n ack-csi-fuse logs csi-fuse-ossfs-xxxx 
```
- CSI版本為1.30.4之前
```
kubectl -n kube-system logs csi-fuse-ossfs-xxxx 
```
  若Pod處於CrashLoopBackOff狀態，需要查詢上一次異常退出前Pod的日誌：
```
kubectl -n kube-system logs -p csi-fuse-ossfs-xxxx 
```
（可選）如果日誌為空白，或資訊過少無法定位問題，說明日誌等級過高，需要通過以下方式增加相關配置。
說明
該方式無需重新部署新的Debug儲存卷及對應的儲存聲明，但無法直擷取OSS側的rest請求響應。
1. 建立用於Debug的OSS儲存卷，在原儲存卷配置的基礎上，在otherOpts欄位中增加-o dbglevel=debug -o curldbg。使用建立的OSS儲存卷掛載後，通過kubectl logs指令從ossfs Pod擷取Debug日誌。
  重要
  Debug日誌量較大，僅建議在Debug情境使用。
2. 使用以下內容，在kube-system下建立名為csi-plugin的ConfigMap。將日誌等級設為debug。
  說明
  CSI plugin 1.28.2及之前的版本，日誌等級只能設定到info。
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: csi-plugin
  namespace: kube-system
data:
  fuse-ossfs: |
    dbglevel=debug     # 日誌等級
```
  重啟應用所在節點的csi-plugin Pod及csi-provisioner的所有Pod，使Configmap的配置生效，重啟應用Pod觸發重掛載，並確認重掛載後的csi-fuse-ossfs-xxxx已重新部署。
  重要
  ConfigMap為全域配置，Debug完成後，請刪除該ConfigMap，再次重啟節點的csi-plugin Pod及csi-provisioner的所有Pod以關閉Debug日誌。最後重啟應用Pod再次觸發重掛載，避免ossfs產生大量Debug日誌。
分析ossfs容器日誌。
通常ossfs拋錯的原因可以分為兩類，分別為ossfs自身拋錯和ossfs向OSS服務端發送請求後收到非200錯誤碼。以下通過兩種拋錯類型的樣本介紹通用的排查方法。
ossfs自身拋錯
```
ossfs: MOUNTPOINT directory /test is not empty. if you are sure this is safe, can use the 'nonempty' mount option.
```
根據日誌資訊定位，報錯的原因是掛載點路徑非空，可通過增加配置項-o nonempty解決。
說明
根據錯誤記錄檔，可在OSS文檔ossfs常見問題查詢相關解決方案。若未找到相關原因，請提交工單解決。
OSS服務端返回非200錯誤碼
查詢日誌，發現ossfs退出前檢查掛載Bucket時，OSS服務端返回的錯誤碼為404，錯誤原因為NoSuchBucket，錯誤資訊為The specified bucket does not exist。
```
[ERROR]  2023-10-16 12:38:38:/tmp/ossfs/src/curl.cpp:CheckBucket(3420): Check bucket failed, oss response: <?xml version="1.0" encoding="UTF-8"?>
<Error>
  <Code>NoSuchBucket</Code>
  <Message>The specified bucket does not exist.</Message>
  <RequestId>652D2ECEE1159C3732F6E0EF</RequestId>
  <HostId><bucket-name>.oss-<region-id>-internal.aliyuncs.com</HostId>
  <BucketName><bucket-name></BucketName>
  <EC>0015-00000101</EC>
  <RecommendDoc>https://api.aliyun.com/troubleshoot?q=0015-00000101</RecommendDoc>
</Error>
```
通過日誌資訊定位，報錯的原因為掛載的OSS Bucket不存在，可通過登入OSS管理主控台建立Bucket後重新掛載解決。
說明
通過錯誤碼及錯誤原因，可在OSS文檔HTTP錯誤碼中查詢相關的解決辦法。
其他說明
日誌等級說明
如果您的日誌等級過高，無法定位問題，並且包含以下需求：
- 不希望重建OSS儲存卷。
- 擔心全域ConfigMap配置影響其他問題，例如，Debug期間可能發生的其他OSS儲存卷的掛載或卸載。
此時，您可以以前台方式掛載ossfs並擷取Debug日誌進行定位。具體操作，請參見CSI Plugin組件為1.26.6之前的版本問題的處理。
重要
ossfs容器化運行後，節點未預設安裝ossfs。手動安裝的ossfs版本與實際Pod中啟動並執行ossfs版本可能不一致，建議您優先參考上述解決方案，通過變更PV掛載參數或全域ConfigMap配置的方式進行排查。
執行以下操作掛載ossfs。
1. 安裝最新版本的ossfs。
2. 在節點上執行以下操作，擷取PV名稱的sha256值。
```
echo -n "<PV_NAME>" | sha256sum
```
  若系統不支援sha256sum操作，也可使用openSSL庫擷取該值：
```
echo -n "<PV_NAME>" | openssl sha256 -binary | xxd -p -c 256
```
  如對"pv-oss"，預期輸出為：
```
8f3e75e1af90a7dcc66882ec1544cb5c7c32c82c2b56b25a821ac77cea60a928
```
3. 在節點上執行以下操作，擷取ossfs的掛載參數。
```
ps -aux | grep <sha256-value>
```
  預期輸出中包含ossfs的進程記錄。
4. 在節點上執行以下命令，產生ossfs掛載時需要的鑒權資訊。在Debug之後，請您及時清理該檔案。
```
mkdir -p /etc/ossfs && echo "<bucket-name>:<akId>:<akSecret>" > /etc/ossfs/passwd-ossfs && chmod 600 /etc/ossfs/passwd-ossfs
```
段錯誤（Segmentation Fault）排查說明
如果錯誤記錄檔中包含"ossfs exited with error" err="signal: segmentation fault (core dumped) "，表明ossfs進程在運行期間因段錯誤而異常退出。
為協助支援人員定位問題，請登入節點，按照下方流程擷取core dump檔案，並提交工單解決。
1. 尋找 ossfs 進程的崩潰記錄。
```
coredumpctl list
```
  預期輸出：
```
TIME                          PID       UID   GID  SIG   COREFILE   EXE
Mon 2025-11-17 11:21:44 CST   2108767   0     0    1     present    /usr/bin/xxx
Tue 2025-11-18 19:35:58 CST   493791    0     0    1     present    /usr/local/bin/ossfs
```
  以上輸出表明該節點曾發生兩次進程的段錯誤退出。
  根據發生時間TIME和進程名稱EXE找到需要排查的記錄，並記下其對應的 PID。在上述樣本中，PID 為 493791。
2. 匯出 core dump 檔案。使用上一步擷取到的PID，執行以下命令匯出 core 檔案。--output參數用於指定產生的檔案名稱。
```
# 請將 <PID> 替換為實際 PID
coredumpctl dump <PID> --output ossfs.dump
```
3. 提交工單，並提供產生的 ossfs.dump 檔案。

CSI Plugin組件為1.26.6之前的版本

問題現象

業務Pod啟動時，長期處於ContainerCreating狀態。

問題原因

執行以下命令，查詢Pod無法正常啟動的原因。
需替換的變數如下：
- <POD_NAMESPACE>：業務Pod所在的命名空間。
- <POD_NAME>：業務Pod名稱。
```
kubectl -n <POD_NAMESPACE> describe pod <POD_NAME>
```
查詢結果的Events中是否存在原因為FailedMount的事件。
需替換的變數如下：
- <PV_NAME>：OSS儲存卷名稱。
- <BUCKET>：掛載的OSS Bucket名稱。
- <PATH>：掛載的OSS Bucket的路徑。
- <POD_UID>：業務Pod的UID。
- ```
Warning  FailedMount  3s  kubelet  MountVolume.SetUp failed for volume "<PV_NAME>" : rpc error: code = Unknown desc = Mount is failed in host, mntCmd:systemd-run --scope -- /usr/local/bin/ossfs <BUCKET>:/<PATH> /var/lib/kubelet/pods/<POD_UID>/volumes/kubernetes.io~csi/<PV_NAME>/mount -ourl=oss-cn-beijing-internal.aliyuncs.com -o allow_other , err: ..... with error: exit status 1
```
  出現此類事件的原因：CSI組件在拉起ossfs時，ossfs異常退出，此時節點上無對應的ossfs進程在運行。OSS連通性檢查出錯（Bucket不存在，許可權配置錯誤等）、掛載路徑不存在、無讀寫權限等初始化檢查的錯誤都可能導致此錯誤現象。

解決方案

步驟1：擷取原ossfs啟動指令

通過查詢FailedMount事件，查看掛載異常的輸出。具體操作，請參見適用情境1：掛載失敗中的情境1。

通過掛載異常的輸出擷取原ossfs啟動指令。

掛載異常輸出樣本如下：

Warning  FailedMount  3s  kubelet  MountVolume.SetUp failed for volume "<PV_NAME>" : rpc error: code = Unknown desc = Mount is failed in host, mntCmd:systemd-run --scope -- /usr/local/bin/ossfs <BUCKET>:/<PATH> /var/lib/kubelet/pods/<POD_UID>/volumes/kubernetes.io~csi/<PV_NAME>/mount -ourl=oss-cn-beijing-internal.aliyuncs.com -o allow_other , err: ..... with error: exit status 1

其中，在mntCmd中，systemd-run --scope -- 後端內容為原ossfs的啟動指令。擷取到原ossfs啟動指令如下：

/usr/local/bin/ossfs <BUCKET>:/<PATH> /var/lib/kubelet/pods/<POD_UID>/volumes/kubernetes.io~csi/<PV_NAME>/mount -ourl=oss-cn-beijing-internal.aliyuncs.com -o allow_other

步驟2：前台掛載ossfs並擷取Debug日誌

ossfs掛載的目錄存取權限預設為掛載點的所有者，即執行掛載命令的使用者，其他使用者無法訪問。因此若原指令中沒有-o allow_other配置項，可能導致掛載根路徑的許可權問題。

確認是否為掛載點路徑許可權問題。
如果許可權存在問題，請直接在建立PV時，增加配置項-o allow_other。關於ossfs的掛載點目錄存取權限配置，請參見掛載儲存空間，關於如何增加配置項，請參見使用ossfs 1.0靜態儲存卷。

執行以下命令，在業務Pod所在節點以前台方式運行ossfs，並設定日誌為Debug模式。

其中，/test為測試用的掛載點路徑，前台啟動並執行ossfs將把OSS Bucket掛載到/test中。

mkdir /test && /usr/local/bin/ossfs <BUCKET>:/<PATH> /test -ourl=oss-cn-beijing-internal.aliyuncs.com -f -o allow_other -o dbglevel=debug -o curldbg

參數	說明
-f	以前台方式而非守護進程方式運行ossfs，在前台模式下，日誌會輸出到終端螢幕。該參數一般用於調試問題時使用。
-o allow_other	賦予電腦上其他使用者訪問掛載目錄的許可權，避免前台掛載ossfs時，出現新的掛載點路徑許可權問題。
-o dbglevel=debug	設定ossfs的日誌等級為debug。
-o curldbg	開啟libcurl的日誌資訊，用於排查OSS服務端返回的錯誤。

步驟3：分析Debug日誌

以前台方式運行ossfs後，日誌將輸出到終端。通常ossfs拋錯的原因可以分為兩類，分別為ossfs自身拋錯，以及ossfs向OSS服務端發送請求後收到非200錯誤碼。下文分別以兩種拋錯類型的例子介紹通用的排查方法。

下文以掛載失敗情境中，ossfs運行後很快退出為例介紹如何進行問題排查。

ossfs自身拋錯

查詢日誌，發現ossfs退出前列印的錯誤記錄檔如下。

ossfs: MOUNTPOINT directory /test is not empty. if you are sure this is safe, can use the 'nonempty' mount option.

根據日誌資訊定位，報錯的原因是掛載點路徑本為非空，可通過增加配置項-o nonempty解決。

說明

根據錯誤記錄檔，可在OSS文檔ossfs常見問題查詢相關解決方案。若未找到相關原因，請提交工單解決。

OSS服務端返回非200錯誤碼

查詢日誌，發現ossfs退出前列印的OSS服務端的返回碼為404，錯誤原因為NoSuchBucket，錯誤資訊為The specified bucket does not exist。

[INFO]       Jul 10 2023:13:03:47:/tmp/ossfs/src/curl.cpp:RequestPerform(2382): HTTP response code 404 was returned, returning ENOENT, Body Text: <?xml version="1.0" encoding="UTF-8"?>
<Error>
  <Code>NoSuchBucket</Code>
  <Message>The specified bucket does not exist.</Message>
  <RequestId>xxxx</RequestId>
  <HostId><BUCKET>.oss-cn-beijing-internal.aliyuncs.com</HostId>
  <BucketName><BUCKET></BucketName>
  <EC>0015-00000101</EC>
</Error>

通過日誌資訊定位，報錯的原因為掛載的OSS Bucket不存在，可通過登入OSS管理主控台建立Bucket後重新掛載解決。

說明

通過錯誤碼及錯誤原因，可在OSS文檔HTTP錯誤碼中查詢相關的解決辦法。

適用情境2：執行POSIX指令拋錯

CSI Plugin組件為1.26.6及之後的版本

問題現象

業務Pod狀態為Running，但執行讀寫等POSIX指令時ossfs拋錯。

問題原因

確認ossfs容器是否正常運行。
說明
- 命令中的<NODE_NAME>指異常業務Pod所在的節點名稱。
- 命令中的<VOLUME_ID>一般指實際業務PV的名稱，以下兩種情境需要重新擷取該值：
  - PV名稱與PV的volumeHandle欄位的值不同時，需要使用volumeHandle欄位。可使用以下指令擷取某個PV的volumeHandle值：
    kubectl get pv <PV_NAME> -o jsonpath='{.spec.csi.volumeHandle}'
  - PV名稱過長時，<VOLUME_ID>由"h1."與其sha1值拼接得到。可使用以下指令擷取該值：
    echo -n "<PV_NAME>" | sha1sum | sed 's/^/h1./'
    若系統不支援sha1sum操作，也可使用openSSL庫擷取該值：
    echo -n "<PV_NAME>" | openssl sha1 -binary | xxd -p -c 40 | sed 's/^/h1./'
- CSI版本為v1.30.4及之後
```
kubectl -n ack-csi-fuse get pod -l csi.alibabacloud.com/volume-id=<VOLUME_ID> -o wide | grep <NODE_NAME>
```
  由於該版本ossfs容器中新增守護進程，無論ossfs進程是否正常運行，預期輸出均為：
```
NAME                   READY   STATUS             RESTARTS     AGE
csi-fuse-ossfs-xxxx    1/1     Running            0            5s
```
  若ossfs容器處於非Running狀態，請先排查異常原因。
- CSI版本為1.30.4之前
```
kubectl -n kube-system get pod -l csi.alibabacloud.com/volume-id=<VOLUME_ID> -o wide | grep <NODE_NAME>
```
  若ossfs容器運行異常，則預期輸出為：
```
NAME                   READY   STATUS             RESTARTS     AGE
csi-fuse-ossfs-xxxx    0/1     CrashLoopBackOff   1 (4s ago)   5s
```
通過業務的日誌確認發生錯誤的指令及返回的錯誤類型。例如，執行chmod -R 777 /mnt/path指令時返回I/O error。

出現此類事件的原因：CSI組件在拉起ossfs容器後，ossfs Pod正常運行，並在業務Pod所在節點指定的掛載點路徑上掛載OSS Bucket，但在執行chmod、read、open等POSIX指令時，ossfs運行異常並返回錯誤，並在日誌中列印對應錯誤。

解決方案

查詢ossfs容器日誌。
- CSI版本為v1.30.4及之後
```
kubectl -n ack-csi-fuse logs csi-fuse-ossfs-xxxx 
```
- CSI版本為1.30.4之前
```
kubectl -n kube-system logs csi-fuse-ossfs-xxxx 
```
  若Pod處於CrashLoopBackOff狀態，需要查詢上一次異常退出前Pod的日誌：
```
kubectl -n kube-system logs -p csi-fuse-ossfs-xxxx 
```
（可選）如果日誌為空白，或資訊過少無法定位問題，說明日誌等級過高，需要通過以下方式增加相關配置。
說明
該方式無需重新部署新的Debug儲存卷及對應的儲存聲明，但無法直擷取OSS側的rest請求響應。
1. 建立用於Debug的OSS儲存卷，在原儲存卷配置的基礎上，在otherOpts欄位中增加-o dbglevel=debug -o curldbg。使用建立的OSS儲存卷掛載後，通過kubectl logs指令從ossfs Pod擷取Debug日誌。
  重要
  Debug日誌量較大，僅建議在Debug情境使用。
2. 使用以下內容，在kube-system下建立名為csi-plugin的ConfigMap。將日誌等級設為debug。
  說明
  CSI plugin 1.28.2及之前的版本，日誌等級只能設定到info。
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: csi-plugin
  namespace: kube-system
data:
  fuse-ossfs: |
    dbglevel=debug     # 日誌等級
```
  重啟應用所在節點的csi-plugin Pod及csi-provisioner的所有Pod，使Configmap的配置生效，重啟應用Pod觸發重掛載，並確認重掛載後的csi-fuse-ossfs-xxxx已重新部署。
  重要
  ConfigMap為全域配置，Debug完成後，請刪除該ConfigMap，再次重啟節點的csi-plugin Pod及csi-provisioner的所有Pod以關閉Debug日誌。最後重啟應用Pod再次觸發重掛載，避免ossfs產生大量Debug日誌。
分析ossfs容器日誌。
通常ossfs拋錯的原因可以分為兩類，分別為ossfs自身拋錯和ossfs向OSS服務端發送請求後收到非200錯誤碼。以下通過兩種拋錯類型的樣本介紹通用的排查方法。
ossfs自身拋錯
此處以執行chmod -R 777 <業務Pod中的掛載點路徑>指令出錯為例，介紹如何進行問題排查。
1. 若測試ossfs的掛載路徑為/test，則執行以下命令。
```
chmod -R 777 /test
```
  查詢日誌後，發現掛載點路徑/test下的檔案Chmod成功，而Chmod /test自身的錯誤記錄檔如下。
```
[ERROR]  2023-10-18 06:03:24:/tmp/ossfs/src/ossfs.cpp:ossfs_chmod(1745): Could not change mode for mount point.
```
  根據日誌資訊定位，掛載點路徑不支援通過Chmod變更許可權。關於如何修改掛載點的許可權，請參見ossfs 1.0儲存卷FAQ。
  說明
  根據錯誤記錄檔，可在OSS文檔ossfs常見問題查詢相關解決方案。若未找到相關原因，請提交工單解決。
OSS服務端返回非200錯誤碼
下文以對Bucket中的某個對象進行操作時，都返回錯誤為例，介紹如何進行問題排查。
```
[INFO]        2023-10-18 06:05:46:/tmp/ossfs/src/curl.cpp:HeadRequest(3014): [tpath=/xxxx]
[INFO]        2023-10-18 06:05:46:/tmp/ossfs/src/curl.cpp:PreHeadRequest(2971): [tpath=/xxxx][bpath=][save=][sseckeypos=-1]
[INFO]        2023-10-18 06:05:46:/tmp/ossfs/src/curl.cpp:prepare_url(4660): URL is http://oss-cn-beijing-internal.aliyuncs.com/<bucket>/<path>/xxxxx
[INFO]        2023-10-18 06:05:46:/tmp/ossfs/src/curl.cpp:prepare_url(4693): URL changed is http://<bucket>.oss-cn-beijing-internal.aliyuncs.com/<path>/xxxxx
[INFO]        2023-10-18 06:05:46:/tmp/ossfs/src/curl.cpp:RequestPerform(2383): HTTP response code 404 was returned, returning ENOENT, Body Text:
```
執行出錯的指令，發現退出前列印的OSS服務端的HTTP返回碼為404。推斷原因為該對象在OSS服務端中不存在。關於出現該現象的原因及對應的解決辦法，請參見404錯誤。
說明
通過錯誤碼及錯誤原因，可在OSS文檔HTTP錯誤碼中查詢相關的解決辦法。
其他說明
日誌等級說明
如果您的日誌等級過高，無法定位問題，並且包含以下需求：
- 不希望重建OSS儲存卷。
- 擔心全域ConfigMap配置影響其他問題，例如，Debug期間可能發生的其他OSS儲存卷的掛載或卸載。
此時，您可以以前台方式掛載ossfs並擷取Debug日誌進行定位。具體操作，請參見CSI Plugin組件為1.26.6之前的版本問題的處理。
重要
ossfs容器化運行後，節點未預設安裝ossfs。手動安裝的ossfs版本與實際Pod中啟動並執行ossfs版本可能不一致，建議您優先參考上述解決方案，通過變更PV掛載參數或全域ConfigMap配置的方式進行排查。
執行以下操作掛載ossfs。
1. 安裝最新版本的ossfs。
2. 在節點上執行以下操作，擷取PV名稱的sha256值。
```
echo -n "<PV_NAME>" | sha256sum
```
  若系統不支援sha256sum操作，也可使用openSSL庫擷取該值：
```
echo -n "<PV_NAME>" | openssl sha256 -binary | xxd -p -c 256
```
  如對"pv-oss"，預期輸出為：
```
8f3e75e1af90a7dcc66882ec1544cb5c7c32c82c2b56b25a821ac77cea60a928
```
3. 在節點上執行以下操作，擷取ossfs的掛載參數。
```
ps -aux | grep <sha256-value>
```
  預期輸出中包含ossfs的進程記錄。
4. 在節點上執行以下命令，產生ossfs掛載時需要的鑒權資訊。在Debug之後，請您及時清理該檔案。
```
mkdir -p /etc/ossfs && echo "<bucket-name>:<akId>:<akSecret>" > /etc/ossfs/passwd-ossfs && chmod 600 /etc/ossfs/passwd-ossfs
```
段錯誤（Segmentation Fault）排查說明
如果錯誤記錄檔中包含"ossfs exited with error" err="signal: segmentation fault (core dumped) "，表明ossfs進程在運行期間因段錯誤而異常退出。
為協助支援人員定位問題，請登入節點，按照下方流程擷取core dump檔案，並提交工單解決。
1. 尋找 ossfs 進程的崩潰記錄。
```
coredumpctl list
```
  預期輸出：
```
TIME                          PID       UID   GID  SIG   COREFILE   EXE
Mon 2025-11-17 11:21:44 CST   2108767   0     0    1     present    /usr/bin/xxx
Tue 2025-11-18 19:35:58 CST   493791    0     0    1     present    /usr/local/bin/ossfs
```
  以上輸出表明該節點曾發生兩次進程的段錯誤退出。
  根據發生時間TIME和進程名稱EXE找到需要排查的記錄，並記下其對應的 PID。在上述樣本中，PID 為 493791。
2. 匯出 core dump 檔案。使用上一步擷取到的PID，執行以下命令匯出 core 檔案。--output參數用於指定產生的檔案名稱。
```
# 請將 <PID> 替換為實際 PID
coredumpctl dump <PID> --output ossfs.dump
```
3. 提交工單，並提供產生的 ossfs.dump 檔案。

CSI Plugin組件為1.26.6之前的版本

問題現象

業務Pod狀態為Running，但執行讀寫等POSIX指令時ossfs拋錯。

問題原因

藉助業務的日誌確認發生錯誤的指令及返回的錯誤類型。例如，執行chmod -R 777 /mnt/path指令時返回I/O error。

執行以下命令，進入業務Pod確認。

kubectl -n <POD_NAMESPACE> exec -it <POD_NAME> -- /bin/bash

bash-4.4# chmod -R 777 /mnt/path
chmod: /mnt/path: I/O error

出現此類事件的原因：CSI組件在拉起ossfs後，ossfs進程正常運行，並在業務Pod所在節點指定的掛載點路徑掛載OSS Bucket。但在執行chmod、read、open等POSIX指令時，ossfs運行異常並返回錯誤。

解決方案

步驟1：擷取原ossfs啟動指令

由於ossfs已在節點上運行，您可以通過OSS儲存卷名稱在業務Pod所在的節點上執行以下指令，擷取原ossfs啟動指令。

ps -aux | grep ossfs | grep <PV_NAME>

預期輸出：

root     2097450  0.0  0.2 124268 33900 ?        Ssl  20:47   0:00 /usr/local/bin/ossfs <BUCKET> /<PATH> /var/lib/kubelet/pods/<POD_UID>/volumes/kubernetes.io~csi/<PV_NAME>/mount -ourl=oss-cn-beijing-internal.aliyuncs.com -o allow_other

將預期輸出中<BUCKET>後面的空格替換為冒號（:），即由<BUCKET> /<PATH>改為<BUCKET>:/<PATH>，擷取到原ossfs啟動指令如下。

/usr/local/bin/ossfs <BUCKET>:/<PATH> /var/lib/kubelet/pods/<POD_UID>/volumes/kubernetes.io~csi/<PV_NAME>/mount -ourl=oss-cn-beijing-internal.aliyuncs.com -o allow_other

步驟2：前台掛載ossfs並擷取Debug日誌

確認是否為掛載點路徑許可權問題。
如果許可權存在問題，請直接在建立PV時，增加配置項-o allow_other。關於ossfs的掛載點目錄存取權限配置，請參見掛載儲存空間，關於如何增加配置項，請參見使用ossfs 1.0靜態儲存卷。

執行以下命令，在業務Pod所在節點以前台方式運行ossfs，並設定日誌為Debug模式。

其中，/test為測試用的掛載點路徑，前台啟動並執行ossfs將把OSS Bucket掛載到/test中。

mkdir /test && /usr/local/bin/ossfs <BUCKET>:/<PATH> /test -ourl=oss-cn-beijing-internal.aliyuncs.com -f -o allow_other -o dbglevel=debug -o curldbg

參數	說明
-f	以前台方式而非守護進程方式運行ossfs，在前台模式下，日誌會輸出到終端螢幕。該參數一般用於調試問題時使用。
-o allow_other	賦予電腦上其他使用者訪問掛載目錄的許可權，避免前台掛載ossfs時，出現新的掛載點路徑許可權問題。
-o dbglevel=debug	設定ossfs的日誌等級為debug。
-o curldbg	開啟libcurl的日誌資訊，用於排查OSS服務端返回的錯誤。

步驟3：分析Debug日誌

執行POSIX失敗情境中，需要另起終端執行出錯的指令，並分析執行新列印的ossfs日誌。

ossfs自身拋錯

下文以執行chmod -R 777 <業務Pod中的掛載點路徑>指令出錯為例，介紹如何進行問題排查。

由於測試ossfs進程掛載至/test路徑下，則需執行的指令如下。

chmod -R 777 /test

查詢日誌，發現掛載點路徑/test下的檔案Chmod成功，而Chmod /test本身的錯誤記錄檔如下。

[ERROR] Jul 10 2023:13:03:18:/tmp/ossfs/src/ossfs.cpp:ossfs_chmod(1742): Could not change mode for mount point.

根據日誌資訊定位，掛載點路徑不支援通過Chmod變更許可權。關於如何修改掛載點的許可權，請參見ossfs 1.0儲存卷FAQ。

說明

根據錯誤記錄檔，可在OSS文檔ossfs常見問題查詢相關解決方案。若未找到相關原因，請提交工單解決。

OSS服務端返回非200錯誤碼

下文以對Bucket中的某個對象進行操作時，都返回錯誤為例，介紹如何進行問題排查。

[INFO]       Aug 23 2022:11:54:11:/tmp/ossfs/src/curl.cpp:RequestPerform(2377): HTTP response code 404 was returned, returning ENOENT, Body Text: <?xml version="1.0" encoding="UTF-8"?>
<Error>
  <Code>NoSuchKey</Code>
  <Message>The specified key does not exist.</Message>
  <RequestId>xxxx</RequestId>
  <HostId><BUCKET>.oss-cn-beijing-internal.aliyuncs.com</HostId>
  <Key><object-name></Key>
  <EC>0026-00000001</EC>
</Error>

執行出錯的指令，發現退出前列印的OSS服務端的返回碼為404，錯誤原因為NoSuchKey，錯誤資訊為The specified key does not exist。

根據日誌資訊定位，該對象在OSS服務端中不存在。關於出現該現象的原因及對應的解決辦法，請參見NoSuchKey。

說明

通過錯誤碼及錯誤原因，可在OSS文檔HTTP錯誤碼中查詢相關的解決辦法。

排查說明

適用情境1：掛載失敗

CSI Plugin組件為1.26.6及之後的版本

問題現象

問題原因

解決方案

ossfs自身拋錯

OSS服務端返回非200錯誤碼

其他說明

日誌等級說明

段錯誤（Segmentation Fault）排查說明

CSI Plugin組件為1.26.6之前的版本

問題現象

問題原因

解決方案

步驟1：擷取原ossfs啟動指令

步驟2：前台掛載ossfs並擷取Debug日誌

步驟3：分析Debug日誌

ossfs自身拋錯

OSS服務端返回非200錯誤碼

適用情境2：執行POSIX指令拋錯

CSI Plugin組件為1.26.6及之後的版本

問題現象

問題原因

解決方案

ossfs自身拋錯

OSS服務端返回非200錯誤碼

其他說明

日誌等級說明

段錯誤（Segmentation Fault）排查說明

CSI Plugin組件為1.26.6之前的版本

問題現象

問題原因

解決方案

步驟1：擷取原ossfs啟動指令

步驟2：前台掛載ossfs並擷取Debug日誌

步驟3：分析Debug日誌

ossfs自身拋錯

OSS服務端返回非200錯誤碼