Docker Desktop Mac 資料掛載怎麼驗收？2026 科研指南

勝出方案：先用無敏感資料的最小樣例驗收主機與容器之間的讀寫、持久化、權限和交付路徑，再投入真實科研資料。這適合在 Apple Silicon Mac 或遠端 macOS 環境執行 Docker Desktop 的研究團隊；若沒有可用的 Mac，遠端 Mac 可作為隔離驗證環境之一。

研究生：需要確認容器能否讀取主機資料，並把結果存回預定位置。
科研人員與實驗室技術支援人員：需要檢查權限、保存方式，以及其他環境能否重現流程。

資料掛載方式對照

容器能讀到檔案，不代表掛載來源正確；容器內看得到輸出，也不代表容器移除後結果仍在。Docker 官方將 bind mount 定義為把主機路徑掛入容器；Docker Desktop 則透過檔案共享機制，讓 Linux 容器存取 Mac 檔案系統。兩者的資料管理位置和生命週期不同，需分開驗收。Docker bind mount 說明與Docker 儲存概覽界定了這些差異。

Docker 說明 volume 的管理方式與 bind mount 不同。科研容器資料持久化要先決定結果要交給誰、存在哪裡，再選掛載方式；不要只因容器執行成功就判定資料流程通過。

主機路徑與容器可見性

Docker Desktop Mac 找不到掛載的科研資料時

先核對掛載來源、容器目標位置與讀寫模式，再確認 Docker Desktop 的檔案共享設定是否涵蓋專案目錄。設定名稱與可用選項可能隨 Docker Desktop 版本或環境而變，應依照官方設定說明核對目前安裝版本。

在專案目錄準備無敏感內容的測試資料夾，再執行：

mkdir -p probe
printf 'mount-check\n' > probe/input.txt

docker run --rm \
  --mount "type=bind,source=$PWD/probe,target=/data" \
  alpine sh -c 'cat /data/input.txt && printf "container-write\n" > /data/output.txt'

cat probe/output.txt

預期容器能讀取 input.txt，Mac 主機也能在 probe/output.txt 找到容器寫入的內容。若找不到，先不要改用真實資料測試。核對實際掛載來源與目的地：

docker inspect --format \
  '{{range .Mounts}}{{println .Type .Source "->" .Destination .RW}}{{end}}' 容器名稱

docker inspect 可檢視容器的掛載資訊，欄位解讀可對照官方命令文件。若 Docker 使用的是遠端 daemon，bind mount 的來源路徑指向 daemon 所在主機，不一定是發出命令的 Mac；這是與本機 Docker Desktop 不同的交接邊界，請參閱遠端 daemon 說明。

通過條件：來源是預期的 Mac 專案路徑、容器目的地符合工作流程，而且主機與容器的測試檔案都能按預期讀寫。

容器停止或重建後的資料持久化

容器內生成的結果檔會不會保存到 Mac，取決於寫入位置。結果若只寫在容器可寫層，不能假設容器刪除後仍可找回；若寫入 bind mount，應在對應主機目錄檢查；若寫入 named volume，則要驗證該 volume 是否仍可重新掛載。Docker 的volume 文件及備份與還原說明可用來確認 Docker 管理資料的存放與維護邊界。

在測試目錄或測試 volume 寫入識別檔後，停止並移除測試容器，再以新的容器重新掛載同一位置讀取。測試 volume 的流程可參考：

docker volume create research-check

docker run --name persistence-check \
  --mount type=volume,source=research-check,target=/results \
  alpine sh -c 'printf "saved-result\n" > /results/result.txt'

docker rm persistence-check

docker run --rm \
  --mount type=volume,source=research-check,target=/results \
  alpine cat /results/result.txt

如選擇 bind mount，則應對主機資料夾做同樣的「寫入、移除容器、重新掛載、讀回」測試。Compose 專案亦應核對服務的掛載宣告，而不是只看命令列；Compose services 的 volumes 欄位文件說明了服務設定中的掛載表達方式。

通過條件：容器重建後仍能從約定的主機目錄或 named volume 讀回測試結果，且團隊已記錄結果的實際保存位置。

輸入完整性與科研結果核對

檔案存在不等於科研結果正確。驗收時要分辨三件事：輸入是否完整傳入、程式是否寫到預定目錄、輸出是否符合研究所需的科學判準。掛載驗收只能確認資料通道和檔案狀態，不能代替分析方法、參數或結果品質的審查。

先在唯讀副本或可還原的測試資料上列出檔名與目錄，再於執行前後計算校驗值：

find input -type f -print | sort
shasum input/sample.txt

# 完成容器測試後，再檢查原始輸入
shasum input/sample.txt
find output -type f -print | sort

用最小可重現樣例逐項排除：容器讀不到檔案，檢查掛載路徑；輸出目錄為空，檢查應用程式實際寫入位置與執行紀錄；原始檔校驗值改變，則停止使用該工作目錄，先查明程式是否覆寫輸入。校驗值相同只能證明檢查的檔案內容未變，不能證明分析結果本身正確。

通過條件：原始資料符合預期、輸出落在指定交付目錄，且檔名、目錄結構與校驗記錄可以供研究者覆核。

權限範圍與讀寫控制

bind mount 的預設讀寫狀態會影響容器能否修改主機資料；Docker 文件亦提醒，掛載可讓容器存取主機路徑，因此授權範圍本身是安全邊界。bind mount 文件說明了唯讀掛載與可寫掛載的差異。

科研分析通常可把輸入資料設為唯讀，另將輸出掛載到獨立的可寫目錄。以 Docker 命令測試時，可使用唯讀選項：

docker run --rm \
  --mount "type=bind,source=$PWD/input,target=/input,readonly" \
  --mount "type=bind,source=$PWD/output,target=/output" \
  alpine sh -c 'cat /input/sample.txt > /output/copy.txt'

測試應以非關鍵樣例進行。不要為了繞過寫入錯誤，把整個家目錄或其他無關目錄開放給容器。若寫入失敗，先確認掛載模式、主機資料夾存取權與容器程式使用的路徑；不要直接擴大權限後就開始正式分析。

通過條件：輸入目錄不能被容器意外改寫，輸出目錄可以按工作流程寫入，授權範圍也只涵蓋任務所需路徑。

檔案交付與工作流程重現

本機 Mac、遠端 Mac 與 Linux HPC 的路徑不是同一個檔案系統。Mac 上驗收通過，只能證明該環境中的路徑與權限符合預期；若工作流程切換到遠端 daemon 或 HPC，必須重新確認資料如何送達運算端、結果如何回到交付位置。

記錄 Compose 檔或完整執行參數、輸入與輸出路徑約定、唯讀或可寫設定，以及測試資料的清理方式。再以乾淨副本重跑驗收，確認新環境不依賴個人主目錄中的隱藏檔案。若研究資料需跨環境傳輸，也要依課題組規範選擇核准的傳輸方式，避免把敏感資料放入未授權的同步位置。

Docker Desktop 的備份與還原說明可用來了解 Docker 管理資料的維護邊界；但這不等於專案中的 bind mount 已有備份。Mac 主機目錄、Docker volume 與遠端儲存應分別確認備份責任。

通過條件：另一位組員能依記錄重建掛載設定，從約定位置讀取輸入，並把輸出交付到可核對的位置。

驗收矩陣與放行判定

全部符合時，才將這套掛載流程帶入真實課題；任何一項未通過，都應先修正環境，不要把容器成功啟動當成資料交付完成。若團隊還在評估是否需要額外的 Mac，可先查看 SFTPMAC 的 Mac 租用資訊，再依研究資料規範與實際工作流程決定。

Linux HPC 適合其支援的批次運算，但不能代替 macOS 主機路徑驗收；臨時借用同事的 Mac，也可能讓執行設定與檔案交接分散在個人環境。若課題確實需要 macOS、手邊又沒有可用設備，租用 SFTPMAC 的 Mac 作為隔離驗收環境，能讓路徑測試與個人日常主機分開進行。相反地，若工作需要長期持續運算、實體介面，或資料政策不允許遠端處理，則應優先採用符合校方規範的本機或實驗室設備。租用前可由 SFTPMAC 服務頁面了解可用方案；先用公開或脫敏樣例完成驗收，再決定是否用於實際課題。