旧安卓手机改NAS：Docker安装卡点与降级方案

旧安卓手机改造成 NAS 并安装 Docker，听起来像是一条把吃灰设备变成家庭服务器的捷径。真到动手阶段，最麻烦的反而不是 Docker 命令，而是安卓内核本身：cgroups、iptables、overlayfs 这些能力在普通手机上常常缺失，或者被厂商裁剪得无法满足 Docker daemon 的启动条件。这篇文章会走完一条完整路线：先判断你的机器到底能不能跑 Docker，再用 Termux 加 proot-distro 搭出 Linux 环境，尝试安装 Docker Engine，如果跑不通就切换到直接承载服务的降级方案，最后补齐持续运行、远程访问和故障排查清单。

先把结论放在前面：旧安卓手机做 NAS 是可行的，而且成本很低；“直接跑 Docker 当服务器”则需要看内核和 root 情况，不是所有机器都能一次成功。如果你目标是先把文件共享、下载工具和简单 Web 服务跑起来，这篇路线已经够用；如果目标是一定要在安卓上运行完整 Docker 容器，你也需要先理解卡点在哪里。

1. 先想清楚：旧安卓手机跑 Docker 到底卡在哪

1.1 这条改造路线的真实主线是什么

把旧手机改 NAS，本质上是把这台设备当成一台低功耗的 Linux 小主机来用。它不需要显示器，不需要键鼠，只需要一个能长期开机的供电方式、一个稳定网络环境，以及一套能跑服务的操作系统级环境。

改造链路可以分成四步：先拿到可用的 Linux 运行环境，再考虑容器运行时，然后规划数据目录和网络访问，最后解决自启、日志和散热。标题里提到的 Docker 只是中间一环，而不是全部。很多教程把“安装 Docker”当成终极目标，忽略了旧手机真正的问题是内核能力不足。

实际项目中更推荐这样看待这条链路：

• 第一步：让手机里能稳定跑一个 Debian 或 Ubuntu 环境。
• 第二步：在这个环境里尝试安装 Docker Engine。
• 第三步：如果 Docker daemon 起不来，不要死磕，直接用 Linux 软件包承载 NAS 服务。
• 第四步：把服务启动脚本和 docker-compose 文件都保留下来，将来换到支持 Docker 的机器上可以直接复用。

这个顺序能保证你至少得到一个可用的 NAS，而不是卡在 Docker 启动日志上。

1.2 Docker 在安卓侧缺少的内核能力

Docker 不是一个普通应用，它依赖 Linux 内核提供多种能力。安卓手机的系统内核虽然也是 Linux 内核，但厂商通常会对内核做一些裁剪，或者没有开放必要配置。最常影响 Docker 启动的有三个地方：

第一个是 cgroups。cgroups 用于限制和统计容器资源，Docker daemon 启动时会读取 /proc/cgroups，并尝试在 /sys/fs/cgroup 下创建控制组。很多安卓内核里 cgroup 没有启用或没有挂载，Docker 就会报资源系统不可用。

第二个是 iptables 和 netfilter。Docker 创建 bridge 网络时，需要写入 iptables 规则来实现端口映射和容器间通信。普通用户权限下没有 CAP_NET_ADMIN，proot 环境中更是拿不到这个能力，所以 bridge 网络经常创建失败。

第三个是 overlayfs。Docker 默认使用 overlay2 作为存储驱动，要求内核支持 overlay 文件系统。如果内核没有启用 CONFIG_OVERLAY_FS，Docker 会退回到其他驱动，或者直接启动失败。

可以先在 Termux 里跑几条命令看看基础情况：

bash复制cat /proc/cgroups
ls /sys/fs/cgroup 2>/dev/null | head
cat /proc/filesystems | grep -E "overlay|squashfs"
iptables -L 2>/dev/null | head -n 10
cat /proc/meminfo | head -n 5

对这些输出做初步判断：

• /proc/cgroups 里的子系统少于常规 Linux，说明内核裁剪明显。
• /sys/fs/cgroup 为空或不存在，说明 cgroup 没有挂载。
• 输出里没有 overlay，说明 overlay2 存储驱动用不了。
• iptables 命令报错或没有输出规则，说明网络相关能力受限。

这些检测结果直接决定后面能不能跑完整 Docker。

1.3 三条路线怎么选

在旧安卓手机上跑 Linux 环境，常见有三条路线，难度和 Docker 可运行性差别很大。

普通旧手机没有 root 的情况下，proot-distro 是相对务实的选择。它能让你用 apt install 安装大量 Linux 软件，代价是性能损耗和部分内核能力不可用。

如果手机能 root，而且内核恰好保留了 cgroups、iptables、overlayfs 等模块，才有完整 Docker 的希望。即便如此，也需要把 Linux 发行版放在 chroot 环境里，手动处理 cgroup 挂载，过程比 proot 复杂得多。

2. 环境准备：手机选型、系统要求和 Termux 初始化

2.1 什么样的旧手机值得改成 NAS

不是所有旧手机都适合。先按下面这份检查清单过一遍，能避免浪费时间。

如果手机是纯 32 位，或者内存只有 1GB，建议直接放弃完整 Docker 路线。你仍然可以尝试用 proot 跑一个非常小的 Debian，但只适合跑 SSH 和静态文件服务。

另一个容易忽略的条件是 Android 系统版本。新版 Termux 要求 Android 7 以上，如果手机系统停留在 Android 5 或 6，安装完可能无法正常更新包列表。可以先装一个旧版 Termux 或考虑刷机升级系统，但刷机本身有变砖风险，需要先确认设备是否还有第三方系统支持。

2.2 安装 Termux 并完成基础授权

Termux 是这条路线的基础。不要从 Play 商店下载 Termux，Play 版已经长时间不更新，推荐从 F-Droid 或 Termux 官方渠道获取较新版本。

安装完成后，打开 Termux，先做基础更新：

bash复制pkg update -y
pkg upgrade -y
pkg install -y proot-distro openssh rsync curl wget tar
termux-setup-storage

termux-setup-storage 的作用是让 Termux 获得访问手机共享存储的权限。执行后系统会弹出文件访问授权窗口，需要手动同意。这一步很重要，因为后面数据目录可能放到 /sdcard 或外部存储卡上。

接着确认 Termux 主目录和磁盘空间：

bash复制echo "$PREFIX"
echo "$HOME"
df -h

Termux 的家目录通常位于应用私有目录下，空间取决于手机系统和应用占用。如果空间偏小，优先把临时文件和大体积包放到共享存储中，但要注意后续 proot 环境里访问共享存储的路径和权限。

2.3 校准架构、存储和电源状态

进入下一步之前，建议把三个基础信息记录下来，它们会影响后面所有选择。

第一个是架构。运行：

bash复制uname -m

输出 aarch64 表示 64 位 ARM，这类设备能选择的大多数 Docker 镜像都以 arm64 为主。输出 armv7l 则属于 32 位，能用的现代镜像会少很多。

第二个是内存和存储。运行：

bash复制free -h
df -h /data

如果内存只有 2GB，建议同一时间只跑一个服务；如果是 4GB，可以同时跑 SSH、文件共享和下载服务。存储方面要重点看 /data 目录的剩余空间，Docker 镜像和解压后的 rootfs 都会占用这里。

第三个是电源状态。开发调试阶段可以插着电源操作，但长期运行前需要检查电池是否鼓包、充电时温度是否过高。旧手机长期通电还要注意厂商的充电管理策略，有些机器会一直充电到 100%，电池容易发热，需要考虑拆电池直连供电或者限制充电比例。

3. 搭出 Linux 环境，再尝试安装 Docker Engine

3.1 用 proot-distro 安装 Debian 或 Ubuntu

proot-distro 是 Termux 社区常用的 Linux 发行版安装工具，不需要 root 就能运行 Debian、Ubuntu 等系统。虽然它只是通过 proot 模拟目录环境和系统调用，不能提供完整内核能力，但作为 NAS 服务的运行底座已经足够了。

安装 Debian：

bash复制proot-distro install debian
proot-distro login debian

登录后第一件事是更新软件源：

bash复制apt update
apt upgrade -y

如果网络很慢，先确认 /etc/resolv.conf 是否正常，再考虑更换 apt 镜像源。proot 环境里的 DNS 设置可能继承自 Termux，遇到无法解析域名时优先检查这里。

平时进入这个环境的命令是：

bash复制proot-distro login debian

退出环境直接输入 exit。每次重新登录后，之前安装的软件包和数据都还在，因为它们存放在 proot-distro 的 rootfs 目录里。

Debian 和 Ubuntu 的选择本身没有绝对标准。Debian 稳定且体积小；Ubuntu 软件版本更新，但 rootfs 体积更大。旧手机存储紧张时先选 Debian。

3.2 在发行版内安装 Docker 与 Compose

在 proot 的 Debian 里安装 Docker 其实没有任何障碍，因为 Docker 只是普通软件包，能不能运行取决于内核。安装命令：

bash复制apt install -y docker.io docker-compose

这里 docker.io 是 Debian 仓库中的 Docker 引擎包，docker-compose 提供容器编排命令。如果你的发行版提供的是 docker compose 插件，命令可能是 docker compose，可以根据 docker compose version 的输出来确认。

安装完成后，先不要急着启动 daemon，先检查命令是否可用：

bash复制docker version
which dockerd
dockerd --version

正常情况下能看到客户端版本和 dockerd 版本。这里要特别说明一点：安装成功只代表文件就位，不代表 daemon 能启动。接下来真正决定成败的是启动这一步。

3.3 启动 dockerd，并用日志判断能否运行

在 proot 环境里尝试启动 Docker daemon：

bash复制dockerd > ~/dockerd.log 2>&1 &
sleep 8
docker info 2>&1 | head -n 40

如果 docker info 能输出 Server Version 和 Storage Driver，说明 daemon 已经起来了。这时候可以继续尝试：

bash复制docker run hello-world

但更常见的情况是连接失败，或者日志中直接出现明显报错。查看日志：

bash复制tail -n 50 ~/dockerd.log

常见的失败日志可以分为几类：

需要接受一个现实：在绝大多数非 root 的 proot 环境中，完整 Docker daemon 都启动不了。这不是命令写错，而是安卓内核没有提供足够能力。只有当手机已经 root，并且内核具备相应模块时，才建议继续尝试。

如果确实想追完整 Docker，路线应该转向 root 加 chroot：把 Debian/Ubuntu rootfs 放到一个目录，用 chroot 进入，手动挂载 /proc、/sys 和 /sys/fs/cgroup，然后以 root 身份启动 dockerd。这个过程的成败高度依赖具体机型的内核，不能用同一个脚本在所有机器上复现。

3.4 内核能力评估矩阵与下一步决策

当 Docker 启动失败时，不要盲目重试，按下面的决策矩阵走：

如果决定不再折腾 Docker，下面这一章就是你的主路线。docker-compose 文件仍然可以保留，等以后换到支持 Docker 的设备时再迁移。

4. 跑不通后的降级路线：直接用 Linux 服务替代容器

4.1 什么时候应该放弃完整 Docker

放弃完整 Docker 不是失败，而是旧手机上更务实的操作。判断依据很简单：如果 Docker daemon 连续三次启动都因为 operation not permitted 或 overlayfs not supported 失败，并且手机没有 root，就不要再花时间了。

此时要转变思路：容器不是目的，服务才是目的。旧手机作为 NAS，真正需要的是 SSH、文件共享、HTTP 下载、下载工具这些具体能力。这些能力完全可以由 Debian 里的普通软件提供。

这种方式还有一个额外好处：它比 Docker 更适合低内存设备。容器本身会引入额外进程和存储层，在 2GB 内存的旧手机上是额外负担。

4.2 用 SSH、Web 文件共享和下载服务搭出基础 NAS

在 proot 的 Debian 中安装基础服务：

bash复制apt install -y openssh-server python3 nginx-light aria2

先启动 SSH，方便长期管理：

bash复制mkdir -p /run/sshd
/usr/sbin/sshd

默认情况下 SSH 监听 22 端口。在局域网内应该把密码改强，或者直接配置公钥登录。

然后建立 NAS 数据目录：

bash复制mkdir -p ~/nas/html
echo "old phone nas" > ~/nas/html/index.txt

最简单的文件共享方式是 Python 自带的 HTTP 服务：

bash复制cd ~/nas/html
python3 -m http.server 8080 &

这个命令会让局域网设备通过 http://手机IP:8080 访问目录列表，并下载文件。它虽然功能简单，但足够验证链路是否通顺。

如果需要目录浏览体验更好，可以改用 nginx。修改 /etc/nginx/sites-available/default，把 root 指向 ~/nas/html，然后启动 nginx：

bash复制nginx

下载工具用 aria2：

bash复制mkdir -p ~/nas/downloads
aria2c --enable-rpc --rpc-listen-port=6800 --dir=~/nas/downloads &

aria2 启动后会提供 RPC 接口，配合 Aria2 图形客户端可以把下载任务提交到旧手机上。注意 6800 端口只应暴露在局域网内，不要直接映射到公网。

4.3 把业务同时写成容器编排和非容器脚本

即使当前不能跑 Docker，也建议把两种启动方式都写下来。这样可以避免将来换设备时重新设计。

项目目录结构可以这样组织：

code复制~/nas/
├── docker-compose.yml
├── html/
├── downloads/
└── scripts/
    ├── start-services.sh
    └── start-docker.sh

非容器方案启动脚本：

bash复制#!/bin/bash
cd ~/nas

/usr/sbin/sshd
aria2c --enable-rpc --rpc-listen-port=6800 --dir=~/nas/downloads &> ~/nas/aria2.log &
cd ~/nas/html
python3 -m http.server 8080 &> ~/nas/http.log &

echo "services started"

容器方案使用 docker-compose 文件：

yaml复制services:
  fileserver:
    image: nginx:alpine
    container_name: nas-fileserver
    restart: unless-stopped
    network_mode: host
    volumes:
      - ./html:/usr/share/nginx/html:ro

启动脚本：

bash复制#!/bin/bash
cd ~/nas
docker compose up -d

这里提前把 network_mode 设置为 host。原因是旧安卓环境下的 Docker 网络能力不可靠，bridge 网络和端口映射很可能失败，host 模式能绕开一部分网络问题。代价是端口直接占用宿主机端口，需要提前规划端口号。

4.4 自启、防休眠、日志保留

proot 环境没有 systemd，restart: unless-stopped 这类 Docker 策略也无法由系统自动执行。需要自己解决持续运行问题。

Termux 提供 wake lock 能力，可以防止系统休眠时 CPU 进入深度睡眠：

bash复制termux-wake-lock

如果使用 Termux:Boot 这类开机启动插件，可以把 start-services.sh 放到启动脚本目录，让手机重启后自动拉起服务。不同插件的脚本目录不同，以实际配置为准。

日志建议统一重定向到固定文件，并定期清理。在旧手机上，一个不断增长的大日志文件也会造成磁盘压力和 IO 开销。可以写一个简单的清理任务，或者周期性执行：

bash复制truncate -s 0 ~/nas/*.log

5. 最小闭环实验：做一个局域网 HTTP 文件共享

5.1 实验目标与目录结构

这一章的实验目标很简单：让旧手机在局域网内提供一个 HTTP 文件共享服务，其他设备可以通过浏览器访问并下载文件。

目录结构：

bash复制mkdir -p ~/nas/html
echo "hello from old phone" > ~/nas/html/readme.txt

这个实验同时覆盖两条路线：没有 Docker 时用 Python 或 nginx 提供服务；能运行 Docker 时用同一个目录挂载进容器。业务数据不依赖容器是这里的关键原则。

5.2 非容器路线：python 和 caddy 跑通

先切到数据目录并启动服务：

bash复制cd ~/nas/html
python3 -m http.server 8080 &

验证本机是否正常：

bash复制curl -I http://127.0.0.1:8080/readme.txt

预期看到类似 HTTP/1.0 200 OK 的输出。如果一切正常，继续查看手机 IP：

bash复制hostname -I

假设输出是 192.168.1.88，在局域网另一台电脑上执行：

bash复制curl http://192.168.1.88:8080/readme.txt

预期能输出文件内容。这一步通过，就说明旧手机已经具备最基础的 NAS 文件共享能力。

如果觉得 Python 的目录列表样式太朴素，可以装 caddy 或者配置 nginx 的自定义页面。Caddy 的配置更简洁：

bash复制apt install -y caddy
cat <<'EOF' > ~/Caddyfile
:8080 {
    root * /root/nas/html
    file_server browse
}
EOF
caddy run --config ~/Caddyfile

file_server browse 的作用是开启目录浏览，访问者可以看到目录下的所有文件名。

5.3 容器路线：可以运行 Docker 时的等价配置

如果你的机器具备运行 Docker 的条件，用容器跑等价服务。

先把 nginx 容器配置写进 compose 文件：

yaml复制services:
  fileserver:
    image: nginx:alpine
    container_name: nas-fileserver
    restart: unless-stopped
    network_mode: host
    volumes:
      - ./html:/usr/share/nginx/html:ro

启动：

bash复制cd ~/nas
docker compose up -d

因为使用了 network_mode: host，容器内 nginx 默认监听 80 端口。如果宿主机已经占用 80，需要修改 nginx 配置，或者给容器增加启动命令调整监听端口。例如：

yaml复制services:
  fileserver:
    image: nginx:alpine
    network_mode: host
    command: ["nginx", "-g", "daemon off;"]
    volumes:
      - ./html:/usr/share/nginx/html:ro

这里的要点是理解 network_mode: host 的取舍：它牺牲了端口隔离，换取了在受限内核下更高的网络可用性。

5.4 验证清单：从本机到局域网

一个服务是否真正可用，不能只看进程是不是起来了。按这张清单逐项验证：

如果锁屏后服务不响应，优先检查 termux-wake-lock 是否生效，以及系统有没有把 Termux 加入省电白名单。

6. 常见坑：现象、原因、检查方式与处理

6.1 proot 环境中的 apt、sudo 和存储路径问题

在 proot 的 Debian 里经常遇到几个小问题。

第一个是 apt 源慢或超时。现象是 apt update 卡住，或者连接超时。先检查 DNS：

bash复制cat /etc/resolv.conf

如果能解析域名但速度很慢，可以更换 apt 源。具体源地址要按当前发行版和网络环境选择，不要照搬单一路径配置。

第二个问题是 sudo 不可用。proot-distro 默认登录通常是 root 用户，不需要 sudo。如果发行版创建了普通用户，安装 sudo 时注意 apt install -y sudo，然后把用户加入 sudo 组。不要一上来就敲 sudo apt update，容易得到 command not found，让人误以为系统有问题。

第三个问题是存储路径访问不到。Termux 里的 /sdcard 路径在 proot 中不一定绑定，需要先确认当前环境能看到哪些目录。建议把主要数据放在 proot 发行版的用户目录内，比如 /root/nas，然后定期备份到手机共享存储。这样能减少路径权限问题。

6.2 dockerd 启动失败的常见日志与对策

下面这张表汇总了旧安卓环境里最容易遇到的现象和处理方向。

需要特别强调的是，不要因为安装 Docker 包成功就认为 Docker 已能用。安装和运行是完全不同的两件事。旧安卓手机上大概率会卡在 daemon 启动这一环。

如果决定用 vfs 做存储驱动验证，可以在 dockerd 启动参数里加：

bash复制dockerd --storage-driver=vfs > ~/dockerd.log 2>&1 &

vfs 驱动不依赖 overlay 内核模块，但每一次读写都相当于完整复制，性能和磁盘占用都很差，只能用来验证 daemon 是否具备启动条件，不适合长期使用。

6.3 存储空间、休眠被杀、发热和电池鼓包

旧手机长期当服务运行时，最容易忽视的是物理问题。

存储方面，proot 的 rootfs、apt 缓存、日志和下载文件都会占用空间。高频问题是用一段时间后发现磁盘满，服务静默失败。建议每周检查：

bash复制df -h
du -sh ~/nas/*

休眠方面，安卓系统可能在一段时间后杀掉后台进程。即使 Termux 放在前台，系统也可能根据电池策略限制它的活动。需要把 Termux 加入电池优化白名单，并使用 termux-wake-lock 保活。

发热方面，旧手机处于通电和持续负载状态时，温度容易升高。高温会导致降频，进而影响服务响应。把手机放在通风位置，或者用支架垫高，都比闷在抽屉里更合适。

电池方面，长期保持 100% 充电状态可能加速电池老化，甚至出现鼓包风险。如果这台手机打算真正长期服役，应该评估是否拆除电池、直接使用稳定的直流供电方案。这类改造涉及硬件和安全性，需要根据设备型号做评估，不要使用不合格的改造方案。

6.4 这条链路的整体排查顺序

当服务异常时，按下面的顺序排查，能减少无效操作：

1. 先确认命令运行在正确的环境里。Termux 和 proot Linux 是两个环境，装错位置是最常见的问题。
2. 再确认进程是否存活。用 ps aux 看对应服务进程在不在。
3. 然后检查本机端口。用 ss -tlnp 看端口有没有监听。
4. 接着检查本机访问。用 curl 访问 127.0.0.1 的端口。
5. 最后检查局域网访问。确认手机 IP 和访问设备是否在同一子网。
6. 如果局域网访问不到，看手机有没有开启 AP 隔离，或者访问设备防火墙是否拦截。
7. 如果锁屏后失效，回到 termux-wake-lock 和系统电池白名单。

这套顺序可以覆盖大部分情况，也适合移植到其他类似服务器项目上。

7. 长期运行：把旧手机变成真正可用的家庭 NAS

7.1 供电、散热与存储规划的取舍

旧手机当服务器使用，最值钱的不是性能，而是功耗和体积。长期运行要优先解决供电、散热和数据安全。

供电方面，建议提供稳定电源并考虑断电恢复能力。如果服务脚本能开机自动执行，断电重启后就不需要手动干预。散热方面，不要把它塞在弱电箱或抽屉里，至少要保证空气流动。存储方面，重要数据需要多重备份，单纯放在旧手机里并不安全。

内存分配上要有取舍。2GB 内存设备只跑 SSH 和 HTTP 文件共享；4GB 设备可以加 aria2 和图片预览服务；更大内存才考虑多容器或更重的媒体服务。不要一次性把能装的服务全装上，内存耗尽后系统会整体变慢。

7.2 安全基线与内网访问边界

旧手机做 NAS，安全边界一定要清晰。

首先，默认只开放局域网访问。不要把 HTTP 服务、aria2 RPC 端口和 Docker API 端口直接暴露到公网。尤其是 Docker API 默认的 2375 端口，一旦暴露，任何人都可能通过网络操作你的容器环境。

其次，SSH 只保留强认证方式。建议配置公钥登录，并关闭密码登录。配置文件修改后要重启服务生效。

第三，注意系统更新节奏。Termux 和 proot 里的软件包需要定期更新，但旧手机硬件老，不要在业务繁忙时段做大版本升级。先备份服务脚本和数据，再执行 apt upgrade。

7.3 旧手机方案的能力边界与迁移时机

旧手机 NAS 的定位应该是“低成本、低强度、可折腾的家庭实验室”，不是生产级存储设备。

当出现下面这些情况时，值得考虑迁移到树莓派、开发板或二手小主机：

• 手机无法 root，很多服务受权限限制，配置时间成本过高。
• 内存低于 2GB，运行多个服务后频繁 OOM。
• 数据量增长到需要稳定磁盘阵列或 SATA 存储。
• 需要跑 Docker 集群、数据库服务或持续集成任务。
• 手机电池鼓包、接口损坏，每次维护都提心吊胆。

迁移时，之前保留的 docker-compose 文件和启动脚本就能发挥作用。数据目录从旧手机同步到新设备，再执行启动脚本，服务可以快速恢复。

旧安卓手机改造 NAS 的完整价值，不是追求“必须跑起 Docker”，而是把一台已经退役的设备重新派上用场。先把 SSH、文件共享和下载跑通，验证内核是否具备容器条件，再决定要不要继续挑战 Docker。如果 Docker 最终无法启动，提前写好的 compose 文件也不会白费，它会在你迁移到下一台设备时成为最直接的复用资产。