本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

掛載問題疑難排解

接下來，您可以找到有關EFS檔案系統掛載問題疑難排解的資訊。

在 Windows 執行個體上掛載檔案系統失敗

在 Microsoft 視窗上安裝在 Amazon EC2 執行個體上的檔案系統失敗。

採取動作

不要將 Amazon EFS 與 Windows EC2 實例一起使用，這是不受支持的。

伺服器已拒絕存取

檔案系統掛載失敗，並顯示下列訊息：

/efs mount.nfs4: access denied by server while mounting 127.0.0.1:/

如果您的NFS用戶端沒有掛載檔案系統的權限，就會發生這個問題。

採取動作

如果您嘗試使用掛載檔案系統IAM，請確定您正在使用 mount 指令中的-o iam選項。這會告訴EFS掛載協助程式將您的認證傳遞給EFS掛載目標。如果您仍然無法存取，請檢查您的檔案系統原則和身分原則，以確保沒有適用於您的連線的DENY條款，並且至少有一個適用於連線的ALLOW子句。如需詳細資訊，請參閱 用IAM來控制檔案系統資料存取 及 建立檔案系統原則。

自動掛載失敗且執行個體沒有回應

如果檔案系統已自動掛載於執行個體上且沒有宣告 _netdev 選項，則可能發生此問題。如果_netdev遺失，您的EC2執行個體可能會停止回應。此結果是因為網路檔案系統在運算執行個體開始聯網後需要初始化。

採取動作

如果發生此問題，請聯絡 Sup AWS port 部門。

在 /etc/fstab 中掛載多個 Amazon EFS 檔案系統失敗

對於使用 systemd 初始化系統且具有兩個或多個 Amazon EFS 項目的執行個體/etc/fstab，可能會有部分或全部未掛載這些項目的情況。在這種情況下，dmesg 輸出會顯示一或多個類似以下的行。

NFS: nfs4_discover_server_trunking unhandled error -512. Exiting with error EIO

採取動作

在這種情況下，我們建議您在 /etc/systemd/system/mount-nfs-sequentially.service 建立新的 systemd 服務檔案。要包含在檔案中的程式碼取決於您是手動掛載檔案系統還是使用 Amazon EFS 掛載協助程式。

建立檔案后，請執行以下兩個命令：

然後重新啟動 Amazon EC2 實例。檔案系統為隨需掛載，通常可在一秒內完成。

出現「錯誤 fs 類型」錯誤訊息的掛載命令失敗

出現以下錯誤訊息的掛載命令失敗。

mount: wrong fs type, bad option, bad superblock on 10.1.25.30:/, 
missing codepage or helper program, or other error (for several filesystems 
(e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program)
In some cases useful info is found in syslog - try dmesg | tail or so.

採取動作

如果您收到此訊息，請安裝 nfs-utils (或 Ubuntu 的 nfs-common) 套件。如需詳細資訊，請參閱 安裝用NFS戶端。

出現「錯誤的掛載選項」錯誤訊息的掛載命令失敗

出現以下錯誤訊息的掛載命令失敗。

mount.nfs: an incorrect mount option was specified

採取動作

此錯誤訊息很可能表示您的 Linux 發行版本不支援網路檔案系統版本 4.0 和 4.1 (NFSv4)。您可以執行以下命令以確認是否為此情況。

$ grep CONFIG_NFS_V4_1 /boot/config*

如果前面的命令返回# CONFIG_NFS_V4_1 is not set，則 Linux 發行版本不支持 NFSv4 .1。有關支持 NFSv4 1 的 Amazon 彈性計算雲（AmazonAMIs）的 Amazon 機器映像（EC2）列表，請參閱NFS支持。

使用存取點掛載失敗

使用存取點進行掛載時，掛載命令會失敗，並顯示下列錯誤訊息：

mount.nfs4: mounting access_point failed, reason given by server: No such file or directory

採取動作

此錯誤訊息表示指定的EFS路徑不存在。請確定您已提供存取點根目錄的擁有權和權限。EFS不會在沒有此資訊的情況下建立根目錄。如需詳細資訊，請參閱 使用 Amazon EFS 存取點。

如果您未指定任何根目錄擁有權和權限，且根目錄尚未存在，則不EFS會建立根目錄。如果出現以上情況，那麽嘗試使用存取點掛載檔案系統將會失敗。

在檔案系統建立後立即發生檔案系統掛載失敗

為網域名稱服務 (DNS) 記錄建立掛載目標後，最多可能需要 90 秒的時間才能在 AWS 區域.

採取動作

如果您以程式設計方式建立和掛載檔案系統 (例如使用範 AWS CloudFormation 本)，建議您實作等待條件。

檔案系統掛載停止回應，然後因逾時錯誤而失敗

檔案系統掛載命令停止回應一至兩分鐘，然後因逾時錯誤而失敗。下列代碼顯示了範例。

$ sudo mount -t nfs -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport mount-target-ip:/ mnt

[2+ minute wait here]
mount.nfs: Connection timed out
$ 

採取動作

因為 Amazon EC2 執行個體或掛接目標安全群組未正確設定，可能會發生此錯誤。請確定裝載目標安全性群組具有允許從EC2安全性群組NFS存取的輸入規則。如需詳細資訊，請參閱 建立安全群組。

確認您指定的掛載目標 IP 地址為有效。如果您指定了錯誤的 IP 地址，且在該 IP 地址沒有其他內容可拒絕掛載，則您可能會遇到這個問題。

NFS使用DNS名稱掛載檔案系統失敗

嘗試使用用NFS戶端 (不使用用戶amazon-efs-utils端) 使用檔案系統DNS名稱來掛載檔案系統失敗，如下列範例所示：

$ sudo mount -t nfs -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport file-system-id.efs.aws-region.amazonaws.com:/ mnt   
mount.nfs: Failed to resolve server file-system-id.efs.aws-region.amazonaws.com: 
  Name or service not known.   

$   

採取動作

檢查您的VPC組態。如果您使用的是自訂VPC，請確DNS定已啟用設定。如需詳細資訊，請參閱 Amazon VPC 使用者指南VPC中的DNS屬性。此外，檔案系統和掛載目標DNS名稱無法從其所VPC在位置之外解析。

在mount指令中使用檔案系統的DNS名稱來掛載檔案系統之前，必須先執行下列動作：

出現「nfs 未回應」的檔案系統掛載失敗

在傳輸控制通訊協定 (TCP) 重新連線事件上，Amazon EFS 檔案系統掛載失敗。"nfs: server_name still not responding"

採取動作

使用noresvport掛載選項可確保用NFS戶端在重新建立網路連線時使用新的TCP來源連接埠。這可讓您確保網路復原事件後的不中斷可用性。

掛載目標生命週期狀態已停滯

該掛載目標生命週期狀態停滯在建立或刪除狀態。

採取動作

重試 CreateMountTarget 或 DeleteMountTarget 呼叫。

裝載目標生命週期狀態顯示錯

掛載目標生命週期狀態顯示錯誤。

採取動作

如果虛擬私有雲 (DNS) 具有衝突的託管區域，Amazon EFS 無法為新的檔案系統掛載目標建立必要的網域名稱系統 (VPC) 記錄。Amazon EFS 無法在客戶擁有的託管區域內建立新記錄。如果您需要維護具有衝突efs.<region>.amazonaws.com.rproxy.goskope.comDNS範圍的託管區域，請在單獨建立託管區域VPC。如需有關的DNS考量事項的詳細資DNS訊 VPC，請參閱VPC.

若要解決此問題，請從中刪除衝突的efs.<region>.amazonaws.com.rproxy.goskope.comVPC主機，然後再次建立掛載目標。如需建立掛載目標的詳細資訊，請參閱 管理掛載目標。

掛載未回應

Amazon EFS 掛載似乎沒有響應。例如，ls 命令停止回應。

採取動作

如果另一個應用程式正在寫入大量資料到檔案系統，則可能發生此錯誤。對寫入操作尚未完成前的檔案進行存取可能會被拒。一般而言，對正在被寫入的檔案嘗試任何存取的命令或應用程式都可能造成停止回應。例如，當 ls 命令遇到被寫入的檔案時，可能會停止回應。這是因為一些 Linux 發行版本設定了 ls 命令別名，因此除了列出目錄內容外，它也會擷取檔案屬性。

若要解決此問題，請確認其他應用程式正在將檔案寫入 Amazon EFS 掛載，而且檔案處於 Uninterruptible sleep (D) 狀態，如下列範例所示：

$ ps aux | grep large_io.py 
root 33253 0.5 0.0 126652 5020 pts/3 D+ 18:22 0:00 python large_io.py /efs/large_file

在您已確認是這種情況後，您可以等待其他寫入操作完成，或實施解決方法來處理此問題。在 ls 範例中，您可以直接使用 /bin/ls 命令，而不要使用別名。如此可讓命令繼續執行，而不會因正在寫入的檔案而停止回應。一般而言，如果應用程式的資料寫入可以強制定期排清資料 (或許使用 fsync(2))，如此一來可協助其他應用程式改善您的檔案系統回應能力。不過，這項改善措施可能會犧牲應用程式寫入資料時的效能。

掛載的客戶端中斷連線

掛載到 Amazon EFS 檔案系統的用戶端偶爾可能會因為任意數量的原因而中斷連線。NFS用戶端的設計可在發生中斷時自動重新連線，將例行中斷連線對應用程式效能和可用性的影響降到最低。在大多數情況下，用戶端會在數秒內透明地重新連線。

不過，舊版 Linux 核心（v5.4 及以下版本）中所包含的用戶NFS端軟體包含一種行為，導致用NFS戶端在中斷連線時嘗試在相同TCP的來源通訊埠上重新連線。此行為不符合 TCPRFC，而且可以防止這些用戶端快速重新建立與其NFS伺服器的連線 (在本例中為EFS檔案系統)。

若要解決此問題，強烈建議您使用 Amazon EFS 掛載協助程式掛載EFS檔案系統。EFS掛載協助程式使用針對 Amazon EFS 檔案系統最佳化的掛載設定。如需有關EFS用戶端和掛載協助程式的詳細資訊，請參閱安裝 Amazon EFS 客戶端。

如果您無法使用EFS掛載協助程式，我們強烈建議您使用noresvportNFS掛載選項，這會指示用NFS戶端使用新的TCP來源連接埠重新建立連線，以避免此問題。如需詳細資訊，請參閱 建議的NFS掛載設定。

新掛載的檔案系統操作傳回「錯誤的檔案處理」錯誤

新掛載檔案系統執行的操作傳回了 bad file handle 錯誤。

如果 Amazon EC2 執行個體連線到一個檔案系統，而一個具有指定 IP 位址的掛載目標，然後刪除該檔案系統和掛載目標，就會發生此錯誤。如果您建立新的檔案系統並掛載目標以連接到具有相同掛載目標 IP 位址的 Amazon EC2 執行個體，則可能會發生此問題。

採取動作

您可以卸載檔案系統，然後在 Amazon EC2 執行個體上重新掛載檔案系統來解決此錯誤。如需卸載 Amazon EFS 檔案系統的詳細資訊，請參閱卸載檔案系統。

卸載檔案系統失敗

如果您的檔案系統正在忙碌中，則無法將其卸載。

採取動作

您可以透過下列方式來解決問題：