惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

F
Fortinet All Blogs
MyScale Blog
MyScale Blog
Microsoft Security Blog
Microsoft Security Blog
量子位
B
Blog
aimingoo的专栏
aimingoo的专栏
Apple Machine Learning Research
Apple Machine Learning Research
阮一峰的网络日志
阮一峰的网络日志
The GitHub Blog
The GitHub Blog
T
The Exploit Database - CXSecurity.com
N
News | PayPal Newsroom
Cloudbric
Cloudbric
A
About on SuperTechFans
AI
AI
Hacker News: Ask HN
Hacker News: Ask HN
S
Schneier on Security
Recent Commits to openclaw:main
Recent Commits to openclaw:main
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
C
Cyber Attacks, Cyber Crime and Cyber Security
L
LINUX DO - 最新话题
T
The Blog of Author Tim Ferriss
Simon Willison's Weblog
Simon Willison's Weblog
有赞技术团队
有赞技术团队
H
Heimdal Security Blog
J
Java Code Geeks
大猫的无限游戏
大猫的无限游戏
D
Docker
Security Archives - TechRepublic
Security Archives - TechRepublic
N
News and Events Feed by Topic
IT之家
IT之家
Know Your Adversary
Know Your Adversary
N
Netflix TechBlog - Medium
T
Tailwind CSS Blog
B
Blog RSS Feed
C
Cybersecurity and Infrastructure Security Agency CISA
C
Cisco Blogs
博客园 - 叶小钗
美团技术团队
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
H
Hackread – Cybersecurity News, Data Breaches, AI and More
L
LangChain Blog
The Hacker News
The Hacker News
Y
Y Combinator Blog
I
Intezer
The Register - Security
The Register - Security
F
Full Disclosure
V
V2EX
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Last Week in AI
Last Week in AI
Martin Fowler
Martin Fowler

博客园 - 仙守

用audit审计去记录谁用了docker docker容器的磁盘使用进行限额 sentry私有化部署: 在8c16g上降低资源使用 私有化部署sentry: 获取dsn 私有化部署sentry:卷备份及恢复 docker 保存所有镜像 私有化部署sentry:镜像构建 docker拉取代理脚本 vscode密钥从windows连接远程linux 基于docker构建es集群 在es中进行update+upsert milvus遍历查询全部数据 简单剖析qwen-agent回答是怎么获取tool的 一个中转代码,底层调用openai,上层模拟openai 一个小工具识别哪个docker占用gpu NLP之预训练语言模型BERT NLP之预训练语言模型GPT NLP之引言 [推荐系统]粗排之FSCD
docker容器大小使用限制
仙守 · 2026-02-10 · via 博客园 - 仙守

Docker 容器大小與使用者 quota 關係

Created: 2/10/2026 10:08
Updated: 2/10/2026 10:45
Exported: 2/10/2026 10:47

Prompt:

我在linux上用xfs+quota,然后在普通user下限制了这个user的最大磁盘使用量,sudo docker run的容器大小会算在这个user下面吗

Response:

不會,用 sudo docker run 啟動的容器,它的磁碟使用量不會算在普通使用者的 quota 裡。

原因很簡單:

  • Docker daemon 幾乎都是用 root 執行(或用 root 權限的 systemd service)。
  • 容器寫入的資料(overlay2 的 upperdir、diff 層、container 的 rootfs)都是由 root 擁有與建立。
  • XFS 的 user quota 只看檔案的擁有者 UID(這裡是 0,也就是 root)。
  • 所以不管你用哪個普通使用者下 sudo docker run,quota 統計的都是 root 的使用量。

實測常見情況如下:

情境 容器寫入算誰的 quota? 會不會撞到普通 user 的 quota?
docker run (不加 sudo) root 不會
sudo docker run root 不會
non-root docker (rootless mode) 執行 docker 的使用者 會(但你現在不是這種模式)

想讓容器受普通 user quota 限制的可能方式

目前主流做法幾乎都不走 user quota,而是用其他機制:

  1. 最常見做法:用 XFS project quota + overlay2 Docker 官方支援的方式(overlay2 + xfs pquota),可以直接對每個容器設 --storage-opt size=10G,但這是限制容器本身的 rootfs,而且算的是 project quota,不是 user quota。
  2. rootless docker 如果你改用 rootless 模式(docker rootless),容器會以你的普通使用者身份跑,寫入的檔案也屬於你的 UID,這時才真的會受到你設的 user quota 限制。但 rootless 有一些限制(cgroup v2、網路、效能等),而且設定比較麻煩。
  3. bind mount + project quota 把資料目錄 bind 進容器,並對該目錄設 XFS project quota(用 xfs_quota -x -c 'project -s ...'),這樣可以間接限制,但不限制整個容器。

總結: 你現在用 sudo docker run + 一般 user quota 的組合,容器大小不會算進該使用者的限制,它會算 root 的(或完全不受 quota 管,視 /var/lib/docker 是否在有 quota 的 partition)。

如果你真的想限制每個使用者能跑的容器總大小,建議考慮:

  • 改用 rootless docker
  • 或用 XFS project quota 搭配腳本管理(較複雜)
  • 或乾脆用 Kubernetes / Podman + user namespaces 之類的更高階方案

有沒有特別想限制哪一類的使用量(容器 rootfs?還是 volume?)?可以再說詳細一點,我可以給更具體的建議。

Prompt:

那我sudo docker volume create创建的卷,审计的磁盘大小算root的还是user的

Response:

sudo docker volume create 創建的 volume,它的磁碟使用量會算在 root 的 quota 裡,不會算進普通使用者的 user quota。

為什麼這樣?

  • Docker daemon 本身是以 root 身份運行(即使你用 sudo docker 指令,也是 daemon 在處理)。
  • 命名 volume(named volume)的實際資料存放位置在主機上是: /var/lib/docker/volumes/<volume_name>/_data
  • 這個目錄(以及裡面的所有檔案)都是由 root 擁有(uid=0)。
    • 建立時:sudo docker volume create xxx → Docker daemon 用 root 創建目錄。
    • 容器寫入資料時:大多數容器預設以 root 執行(或以容器內的 UID,但映射到 host 還是 root 擁有,除非用 --user 特別指定)。
  • XFS 的 user quota 只統計檔案擁有者是該 UID 的空間使用量。
    • 既然 owner 是 root(0),就會累計到 root 的 quota(如果 root 有設 quota,通常 root 是無限或很高)。
    • 你的普通 user quota 不會被碰觸。

快速驗證方式(你可以自己試)

# 假設你已經設了 user quota 給自己
sudo docker volume create mytestvol

# 看 volume 實際位置與擁有者
sudo ls -ld /var/lib/docker/volumes/mytestvol/_data
# 通常顯示 drwxr-xr-x 2 root root ...

# 再跑個容器寫資料進去
sudo docker run --rm -v mytestvol:/data busybox sh -c "dd if=/dev/zero of=/data/bigfile bs=1M count=100"

# 再看 quota
sudo xfs_quota -x -c 'report -h' /你的quota掛載點
# 你會看到 root 的使用量增加,你的 user 沒變

想讓 volume 受普通 user quota 管?目前主流解法

方法 是否算進你的 user quota 難度/推薦度 說明
用 rootless docker ★★★☆☆(中等) 整個 Docker 跑在你的 UID 下,volume 也屬於你
用 bind mount 而非 named volume 視 bind 的目錄 owner ★★☆☆☆(簡單) docker run -v /home/你用戶名/mydata:/data → owner 是你,就會算你的 quota
XFS project quota + 自訂 volume driver 可針對每個 volume 單獨限額 ★★★★☆(進階) 如 xfsvol plugin 或自己寫 script 設 project ID
乾脆不設 user quota,改用 project quota 管 Docker 整體 ★★★☆☆ Docker 官方推薦方式,用於限容器 rootfs 或 volume

如果你主要目的是「限制每個普通使用者能創建/使用的 volume 總大小」,最乾脆的方式是:

  1. 切換到 rootless docker(官方文件:https://docs.docker.com/engine/security/rootless/),這樣所有 volume、overlay 層都屬於你的 UID,受 user quota 管。
  2. 或改用 bind mount,把資料存在你家目錄下(/home/你的帳號/...),這樣自然受 quota 限制。

有沒有特定場景(例如多人共用一台機器,每人跑自己的容器/volume)?可以再講清楚,我幫你挑最適合的方案。

Prompt:

虽然普通user能sudo+docker,但是他如果bind 卷到指定目录是可以限制的,有什么办法能直接限制指定目录大小,这样也能侧面完成限制特定user的磁盘大小的能力

Response:

是的,你的想法完全正確:當普通使用者用 bind mount 把資料目錄掛進容器時,只要這個目錄的內容屬於該使用者(或寫入的檔案 owner 是該使用者),就能透過 XFS 的機制間接限制使用者的總磁碟用量。

但更精準、更乾淨的方式是使用 XFS project quota 來直接限制「特定目錄樹的大小」,這樣就不用依賴 user quota,也能達到「每個使用者只能用多少空間在自己的 bind 目錄裡」的效果,而且 enforcement 是 kernel 層級的,寫滿就會直接報 ENOSPC(Disk quota exceeded),容器內的寫入也會失敗。

核心做法:XFS project quota 限制特定目錄樹

XFS 的 project quota 專門用來限制「某個目錄及其所有子目錄/檔案」的總大小,不受檔案 owner 是誰影響

步驟(假設你的 XFS 掛載點是 /data,使用者自己的 bind 目錄放在 /data/user-volumes/用戶名):

  1. 掛載時一定要帶上 project quota 選項(pquota 或 prjquota)

    # /etc/fstab 範例(已掛載的要 remount)
    UUID=xxx   /data   xfs   defaults,pquota   0 0
    # 或手動 remount
    sudo mount -o remount,pquota /data
    
  2. 為每個使用者建立一個 project(project ID 可以自己編,從 1000 開始避免衝突)

    # 假設使用者是 xian,project ID 用 2001
    sudo xfs_quota -x -c 'project -s -p /data/user-volumes/xian 2001' /data
    
  3. 設定這個 project 的硬/軟限制(例如 50GB 硬限)

    sudo xfs_quota -x -c 'limit -p bsoft=45g bhard=50g 2001' /data
    # 或用 inode 限制(如果擔心小檔案炸開)
    sudo xfs_quota -x -c 'limit -p isoft=100000 ihard=150000 2001' /data
    
  4. 確認設定

    sudo xfs_quota -x -c 'report -h -p' /data
    # 會看到 project 2001 的使用量和限制
    
  5. 使用者跑容器時 bind 這個目錄

    docker run -v /data/user-volumes/xian:/app/data ...
    

    → 只要寫入的檔案落在 /data/user-volumes/xian 樹下,就會被 project 2001 限制,寫滿直接失敗。

優缺點比較

方法 限制對象 是否 kernel 強制 優點 缺點 / 注意事項
user quota + chown 給 user 使用者所有檔案 最簡單,不用額外管理 project 容器 rootfs 還是 root 的,不受限;需確保 owner 正確
XFS project quota(推薦) 特定目錄樹 精準限制 bind 目錄;不管 owner 是誰 需管理 project ID 對應;初設較麻煩
overlay2 + --storage-opt size 容器 rootfs Docker 原生支援 只限 rootfs,不含 bind volume;需 pquota
zfs / btrfs quota dataset / subvolume 更靈活 換檔案系統成本高

實務建議(多人共用一台機器場景)

  • 建立一個大目錄結構,例如 /data/user-volumes/

  • 寫一個小腳本或 ansible 來自動為新使用者建立 project + 設定 quota

    # 範例腳本片段
    USER=$1
    PROJ_ID=$((2000 + $(id -u $USER)))
    sudo mkdir -p /data/user-volumes/$USER
    sudo chown $USER: /data/user-volumes/$USER
    sudo xfs_quota -x -c "project -s -p /data/user-volumes/$USER $PROJ_ID" /data
    sudo xfs_quota -x -c "limit -p bhard=30g $PROJ_ID" /data
    
  • 強制使用者只能 bind 自己的目錄(可透過 sudoers 或自訂 wrapper 限制 docker run 參數)

  • 定期檢查:sudo xfs_quota -x -c 'report -h' /data

這樣就能側面達到「限制特定 user 的 docker bind volume 磁碟用量」,而且 enforcement 很硬,不怕使用者偷偷寫到別的地方。

有沒有已經存在的目錄結構?或是你希望 quota 怎麼分(每人固定 20G?還是依等級不同?),可以再說,我幫你調整具體指令。

Prompt:

我的意思是通过pquota限制/data/user-volumes/xian这个文件夹的总大小,假如root往里写,也能统计在内,不然sudo+docker之后,进容器用的是root账号,岂不是也无法限制了

Response:

是的,你說得完全正確——這正是 XFS project quota(pquota / prjquota)設計的核心優勢。

project quota 的統計和限制是基於目錄樹(directory tree),而完全獨立於檔案的擁有者(owner UID)。不管檔案是由 root、普通使用者、容器內的 root 還是其他任何人寫入,只要檔案位於被標記為該 project 的目錄樹下,它的空間使用量都會被計入該 project 的總用量,並受到該 project 的 quota 限制。

為什麼即使容器內用 root 寫入也會被限制?

  • 當你用 xfs_quota -x -c 'project -s -p /data/user-volumes/xian 2001' /data 設定 project 時,XFS 會:
    • 遞迴地把 /data/user-volumes/xian 及其所有現有子目錄/檔案的 inode 標上 project ID = 2001。
    • 之後任何新建立在這個樹下的檔案(無論誰建立、owner 是誰),都會自動繼承這個 project ID。
  • 寫入時 kernel 檢查的是 inode 的 project ID,而不是 UID/GID。
  • 所以即使:
    • sudo docker run -v /data/user-volumes/xian:/app/data ...
    • 容器內以 root(UID 0)執行 dd if=/dev/zero of=/app/data/bigfile ...
    • 檔案 owner 在 host 上還是 root:root
    • 但 project ID 是 2001 → 空間算進 project 2001 的用量
  • 一旦達到 bhard(硬限制),寫入就會失敗,報 Disk quota exceeded(ENOSPC),容器內的應用也會看到寫入失敗——不管是 root 還是誰在寫

這就是為什麼 project quota 特別適合你這種「多人/多容器共用 bind mount 目錄,但要限制總大小」的場景。它能有效「側面限制」特定使用者的 docker volume/bind 使用量,即使容器跑在 root 下。

快速確認方式(你可以自己驗證)

  1. 設定好 project quota 後:

    sudo xfs_quota -x -c 'report -h -p' /data
    # 看 project 2001 的 Used 值
    
  2. 用 root 寫大檔案進去:

    sudo dd if=/dev/zero of=/data/user-volumes/xian/bigfile bs=1M count=5000
    # 再 report 一次,Used 會增加(即使 owner 是 root)
    
  3. 超過限制後再寫:

    sudo dd if=/dev/zero of=/data/user-volumes/xian/overflow bs=1M count=10000
    # 會失敗:dd: error writing '/data/...': Disk quota exceeded
    

注意事項(避免踩坑)

  • 必須在掛載時帶 pquota(或 prjquota),否則 project quota 不生效。
    • 檢查:mount | grep /data 要有 pquota 或 prjquota
  • 新建立的子目錄/檔案才會自動繼承 project ID。如果 quota 設定後才創建的目錄沒標上,可以手動重新 -s 一次(通常不需要,因為新寫入會自動)。
  • root 使用者本身不受 user quota 限制,但會受 project quota 限制(除非你特別把 root 的檔案移出 project 樹)。
  • 如果你把整個 /var/lib/docker 設成某個 project,那所有容器(包括 overlay2 層)都會被限制,但這通常不是你想要的——你現在只想限 bind 的使用者目錄。

總結:用 project quota 限制 /data/user-volumes/xian 這個樹,就是你想要的「即使 sudo docker + 容器內 root 寫入,也能統計並限制總大小」的最佳解法。它比 user quota 更適合 docker bind mount 的場景。

如果你已經試過設定,遇到什麼報錯或 report 出來不對,可以貼出來,我幫你 debug 具體指令。或者你想自動化給每個使用者設 project + quota 的腳本,我也都可以再給範例。


Powered by Grok Exporter