修復掛載 Amazon S3 時發生的 Access Denied 錯誤 — NetDrive

在 NetDrive 中掛載 S3 儲存貯體時，磁碟機代號出現在 Windows 檔案總管中，但每個檔案操作都回傳「Access Denied」。磁碟機顯示出來了，卻無法存取任何內容。發生這種情況，是因為 NetDrive 使用的 IAM 認證資訊缺少必要的 S3 動作——或者 IAM 政策正確，但儲存貯體政策覆蓋了它。

將 S3 儲存貯體掛載為本機磁碟機

NetDrive 讓 Google Drive、OneDrive、S3、SFTP、WebDAV 等在 Windows 與 macOS 上顯示為原生磁碟機 — 不需同步，也不需完整下載。

• 支援 Amazon S3 及相容 S3 的儲存服務（Wasabi、MinIO 等）
• 檔案瀏覽器可在掛載前先測試儲存貯體存取權限
• 自 NetDrive 3.19.7 起支援自動偵測 S3 區域

WindowsmacOS

下載 NetDrive →

免費試用。提供終身與訂閱方案。

為什麼掛載的 S3 磁碟機會出現 Access Denied

Amazon S3 的存取權限由兩個獨立的層級控管：連接到你所輸入之存取金鑰所屬使用者或角色的 IAM 政策，以及附加在儲存貯體本身的 儲存貯體政策。任一層級都可能在另一層不知情的情況下拒絕某項操作。

NetDrive 需要至少下列這些 S3 動作，才能正常掛載並使用儲存貯體：

• s3:ListBucket — 用來列出物件並建立目錄檢視
• s3:GetObject — 用來在你開啟檔案時讀取檔案內容
• s3:PutObject — 用來將檔案寫回儲存貯體（僅限讀寫掛載）
• s3:DeleteObject — 用來從掛載的磁碟機刪除檔案（僅限讀寫掛載）

缺少某個動作，會在該特定操作上造成「Access Denied」。你可能可以瀏覽目錄，但在開啟檔案時遭拒；或者可以開啟檔案，卻在儲存時遭拒——這兩者都是 IAM 授權不完整的徵兆，而非完全的認證失敗。

檢查 1：在 NetDrive 中輸入的認證資訊

先從認證資訊本身開始檢查。存取金鑰中的一個字元誤植，或是過期的密鑰，會產生與 IAM 政策設定錯誤相同的「Access Denied」症狀。

1. 開啟 NetDrive → 點按你的 S3 磁碟機上的齒輪圖示，開啟其設定。
2. 逐字比對 Access Key ID 與 AWS 主控台中 IAM → Users → [使用者名稱] → Security credentials 所顯示的值。以複製貼上取代重新輸入。
3. 重新輸入 Secret Access Key。AWS 在建立之後不會再次顯示此值，因此若對其正確性有任何疑慮，請在 IAM 中產生一組新的金鑰配對，並立即以新值更新 NetDrive。
4. 檢查 Region 欄位。區域不符——例如你的儲存貯體位於 eu-west-1，卻設定為 us-east-1——會將請求導向錯誤的端點，並回傳 403 錯誤。NetDrive 3.19.7 為新連線加入了自動區域偵測功能，但升級之前建立的磁碟機設定仍會保留原先輸入的值。如有需要，請手動更新區域。

修正任何認證問題後，點按 Mount，先嘗試瀏覽目錄，再繼續檢查 IAM 層級。

檢查 2：IAM 政策——必要的 S3 動作

如果認證資訊正確，但仍遭拒絕存取，代表所附加的 IAM 政策缺少一項或多項必要動作。確認此點最快的方法是使用 AWS IAM 政策模擬器（Policy Simulator）。

在 AWS 主控台中，前往 IAM → Policy Simulator，選擇金鑰已輸入 NetDrive 的 IAM 使用者，然後針對你的儲存貯體 ARN（arn:aws:s3:::my-bucket）測試 s3:ListBucket，並針對物件 ARN（arn:aws:s3:::my-bucket/*）測試 s3:GetObject。若模擬器回傳「Denied」，請新增一個授予缺少動作的政策。

以下是對單一儲存貯體授予讀寫存取權限的最小政策範例：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": "arn:aws:s3:::my-bucket"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

請注意這裡有兩個不同的 Resource 值：ListBucket 套用於儲存貯體 ARN 本身，而 GetObject、PutObject 與 DeleteObject 則套用於其中的物件（/*）。將它們合併成單一 Resource 是常見的錯誤，會悄悄破壞列表或物件存取功能。

在更新 IAM 政策後，使用 NetDrive 的 File Browser（無需掛載即可使用）快速驗證物件存取是否正常。它會發出與掛載磁碟機相同的 API 呼叫，但不會指派磁碟機代號，讓疑難排解過程中的回饋迴圈更加快速。

檢查 3：儲存貯體政策中的明確拒絕（Explicit Deny）

再寬鬆的 IAM 政策，也會被儲存貯體政策中的明確 Deny 覆蓋。前往 S3 → [你的儲存貯體] → Permissions → Bucket policy，尋找任何 "Effect": "Deny" 陳述式。常見的元兇包括：

• VPC 端點限制 — 拒絕非來自特定 VPC 端點（aws:SourceVpc）請求的政策。桌面版 NetDrive 透過公開網際網路連線，除非你透過 VPN 路由。
• IP 允許清單 — 使用 aws:SourceIp 封鎖來自你機器之公開 IP 位址請求的政策。
• HTTP 拒絕 — 當 aws:SecureTransport 為 false 時拒絕請求的陳述式。這通常無害，因為 NetDrive 的 S3 請求一律使用 HTTPS（自 3.1.234 版起已驗證），但若儲存貯體政策是出於防禦性考量而撰寫，仍值得檢查。

若你發現套用於自身存取模式的限制條件，請放寬該條件，或為 IAM 使用者新增一個具有優先權的明確 Allow。

總結

NetDrive 中的 S3「Access Denied」錯誤幾乎都可以追溯到三個原因之一：認證資訊錯誤、IAM 政策缺少必要動作，或是儲存貯體政策中的明確拒絕。請依此順序逐一排查——認證資訊是最快能排除的一項。若要掛載其他物件儲存服務，請參閱 在 macOS 上掛載 Amazon S3 或 使用 NetDrive 的 DevOps S3 測試固件工作流程。

— Casey, NetDrive