在飞牛fnOS上部署SMB MCP Bridge：让AI智能体读取NAS共享文件-开发者社区

在 NAS 使用场景里，一个很常见的需求是：让 AI 智能体读取 SMB 共享中的文件。飞牛 fnOS 这类基于 Linux 的 NAS 系统自带存储管理和 SMB 文件共享能力，但要把 SMB 共享信息开放给 Claude、Dify、Cline 这类 MCP 客户端，中间还需要一个连接层，也就是 MCP Bridge。MCP Bridge 的作用，是把智能体发出的工具调用请求翻译成 SMB 操作，再把 SMB 返回的文件列表、文件内容翻译回结构化数据。下面按“部署篇”的完整链路来拆解：SMB 共享怎么建、MCP Bridge 怎么在 fnOS 上跑起来、智能体怎么连上去，以及连接失败时该检查哪一段。

这篇文章适合已经有一台飞牛 fnOS 或类似 NAS、想用智能体读取 NAS 文件信息的开发者阅读。文章会从概念讲起，然后给出 Docker Compose 部署示例、MCP 客户端配置示例，以及一份可以直接对着用的排查清单。完成阅读后，你能够自己复现一条“智能体 -> MCP Bridge -> SMB 共享 -> 文件信息返回”的最小链路。

1. 先理解这条链路的组成：SMB、MCP 与 Bridge 各自的职责

1.1 SMB 解决的是文件共享，MCP 解决的是工具调用标准化

SMB（Server Message Block）是网络文件共享协议，Windows、macOS、Linux 都内置支持。飞牛 fnOS 上开启 SMB 服务后，局域网里的电脑或手机可以通过smb://192.168.1.10/share这种方式访问 NAS 上的文件夹。SMB 解决的是“文件如何在网络上被共享、读写、删除”这层问题，它和 NFS、FTP 属于同一类事物。

MCP（Model Context Protocol）是模型上下文协议。简单说，它让 AI 应用通过标准方式连接外部工具和数据源。一个 MCP Server 可以暴露工具、资源和提示词，MCP Client 比如 Claude Desktop、Cline、Dify，会负责发现工具、展示参数、执行调用。你不需要在智能体的提示词里手写一份 “SMB API 文档”，只要把 MCP Server 配置好，智能体就能知道有哪些工具可用，以及每个工具需要传入什么参数。

两者的分工可以这样理解：SMB 负责把文件共享出去，MCP 负责把“读取文件的操作”标准化成智能体可以调用的工具。如果只想让人手动访问 NAS，SMB 就够了；如果想让智能体自动看到文件信息，就必须在 SMB 之上加一层 MCP 封装。

1.2 APEX MCP BRIDGE 在链路里承担什么角色

APEX MCP BRIDGE 在这里可以理解为 MCP 协议和 SMB 协议之间的翻译层。它本身通常是一个运行在 Docker 容器里的服务，内部使用 SMB 客户端工具连接 NAS，对外则以 MCP 协议暴露工具。

常见暴露的工具包括：

列出共享目录
列出目录下的文件
读取文件内容
创建目录或上传文件
删除或重命名文件

当智能体想“查看 SMB 共享目录里有哪些文件”时，MCP Bridge 会接收一个工具调用请求，例如调用list_files，参数是路径/，它再用 SMB 协议连接 NAS，执行目录列举，最后把结果返回给智能体。对智能体来说，它只知道自己调用了一个工具；对 NAS 来说，它只知道有一个 SMB 客户端访问了共享文件。

这里要强调一点：MCP Bridge 不是文件代理服务器。它不会把整个 SMB 共享缓存到本地，每次工具调用都可能发起一次 SMB 连接。因此，SMB 认证速度、局域网连通性和共享目录大小，都会直接影响智能体的响应速度。

1.3 一次最小调用的数据流：从智能体问题到文件列表返回

可以用一个最小示例理解整条链路：

用户提问：“SMB 共享目录下有哪些 PDF 文件？”

数据流如下：

智能体判断需要读取文件信息。
MCP Client 根据工具描述调用list_files，传入路径/。
请求通过 HTTP 或 SSE 发送给 MCP Bridge。
MCP Bridge 使用配置好的 SMB 账号连接飞牛 fnOS 的 445 端口。
SMB 服务读取共享目录，返回文件和文件夹列表。
MCP Bridge 把结果转换成 JSON 返回给 MCP Client。
智能体基于返回结果，生成“目录下有 docs 文件夹和 report.pdf 文件”这样的回答。

整个过程的难点不在任何一步单独执行，而在于七步之间的协议转换和网络连通。后面的部署和排查，基本都围绕这条链路展开。

注意：不要只验证“服务跑起来了”，还要验证“工具被注册了”和“工具调用能返回数据”。服务启动只是第一步。

2. 部署前先把 fnOS 的存储、SMB 共享和账号准备好

2.1 环境清单：fnOS、Docker、SMB 共享与 MCP 客户端

部署前，建议先确认环境。不同版本的 fnOS 界面文字会有差异，但涉及的能力是固定的：

环境项	要求	说明
飞牛 fnOS	能正常访问管理界面	基于 Debian 的 NAS 系统，自带存储管理
Docker 能力	已启用	用于运行 MCP Bridge 容器
SMB 服务	已启用且局域网可访问	需要开放 445 端口
共享文件夹	至少一个测试共享	例如`smb-docs`
SMB 账号	一个专用账号	建议不要使用管理员账号
MCP 客户端	Claude Desktop、Cline、Dify 任一	用于验证工具注册和调用

如果原始环境里没有现成的共享文件夹，先创建测试目录；如果 SMB 服务没有启用，下面的所有配置都不会生效。

2.2 在 fnOS 上创建共享文件夹并启用 SMB 服务

在飞牛 fnOS 上，建议按照下面的顺序操作：

登录 fnOS 管理界面。
进入存储管理器，找到“共享文件夹”或类似入口。
创建一个共享文件夹，例如smb-docs。
在系统设置中启用 SMB 服务。
给smb-docs配置 SMB 访问权限。
记录 fnOS 的局域网 IP，例如192.168.1.10。

创建共享文件夹的目的，是明确“智能体只能看到哪些目录”，避免把整个存储空间暴露给 MCP Bridge。这一步在最初可能被忽略，但一旦以后要收紧权限，重新规划目录的成本会很高。

启用 SMB 时，最好确认一下 SMB 服务监听的协议版本。大部分现代 NAS 会默认启用 SMB2 和 SMB3，Windows 10/11、macOS 以及 Linux 客户端都能正常访问。如果局域网里还有老系统需要访问 SMB，要单独评估协议兼容性，而不是把 SMB1 重新打开。

2.3 创建专用 SMB 账号并设置目录权限

建议创建专用账号，例如mcp-bridge。这个账号只用于 MCP Bridge 连接 NAS，不对应日常管理账号。

权限设置上，遵循最小权限原则：

只给mcp-bridge分配smb-docs目录的读写权限。
如果只需要读取文件，甚至可以只给只读权限。
测试阶段可以先给读写，方便验证上传类工具，生产环境再收窄。

创建账号后，先记录一下账号名和密码。测试阶段密码可以简单一些，后续再改成复杂密码并轮换。

2.4 用 smbclient 或系统资源管理器验证共享可访问

在部署 Bridge 之前，先用其他设备验证 SMB 共享可访问。这一步非常关键：如果 SMB 本身不通，后续所有报错都会被误判成 MCP Bridge 的问题。

Windows 用户可以在资源管理器地址栏输入：

\\192.168.1.10\smb-docs

macOS 用户可以在 Finder 中按Command + K，输入：

smb://192.168.1.10/smb-docs

Linux 用户可以在另一台机器上安装smbclient后用命令行验证：

smbclient -L //192.168.1.10 -U mcp-bridge

如果列出了共享名，说明 SMB 服务和账号是通的。如果出现NT_STATUS_LOGON_FAILURE，说明账号密码有问题；如果出现NT_STATUS_CONNECTION_REFUSED，说明 SMB 服务没有监听或网络端口不通。

推荐先用内网 IP 验证，不要在一开始就使用主机名。因为容器里如果解析不到 NAS 主机名，会额外引入 DNS 问题。

2.5 部署形态：MCP Bridge 建议跑在 fnOS Docker 里

MCP Bridge 的部署形态，通常是在 fnOS 的 Docker 环境中跑一个容器。原因是 MCP Bridge 大多依赖自定义环境变量、端口监听和日志输出，放在容器里更可控，也方便清理。

这时有一个容易踩的坑：如果 Bridge 容器使用 Docker 默认的 bridge 网络，那么容器内访问宿主机时不能使用127.0.0.1，而应该使用 fnOS 的局域网 IP。只有在容器使用 host 网络时，127.0.0.1才指向宿主机本身。

注意：容器内访问 SMB 服务，要写 fnOS 的局域网 IP，不要想当然写127.0.0.1。

3. 为什么选 MCP Bridge：三条技术路径的对比

3.1 三条路径对比：宿主目录、自写 HTTP 服务、MCP Bridge

想让智能体看到 SMB 文件信息，并不是只有 MCP Bridge 一种做法。把常见方案放在一起看，才能理解为什么最后要选 Bridge。

方案	实现方式	优点	缺点
方案 A：直接挂载目录	把 NAS 目录挂载到运行智能体的机器	实现简单，文件系统原生可见	只能在能挂载 SMB 的机器上用，跨机器、跨客户端场景难处理
方案 B：自写 HTTP 服务	自己封装 REST API，内部调用 SMB 命令	可控性强，能做业务逻辑	客户端不通用，每个工具都要管理认证、参数校验、错误处理
方案 C：MCP Bridge	用标准 MCP 协议暴露 SMB 工具	客户端原生支持，工具声明和调用标准化	多一个服务要部署，需要理解 MCP 配置

如果只是本机玩一下，方案 A 确实最省事。但是当智能体跑在另一台服务器，或者你想在多个 MCP 客户端里复用同一套文件操作能力时，方案 C 的优势就比较明显。

3.2 Bridge 在复用性和协议标准化上的优势

选择 MCP Bridge，核心原因是 MCP 协议正在成为智能体连接外部工具的通用接口。同一个 Bridge，可以同时被 Claude Desktop、Cline、Dify 等客户端发现和调用。

这意味着：

工具定义一次，多个客户端复用。
工具参数有 JSON Schema，智能体能够自动生成正确参数。
不需要在系统提示词里写“如何调用文件服务”的文档。
后续增加新工具，只需要在 Bridge 内部实现并重新暴露，客户端自动发现。

自写 HTTP 服务也能达到类似效果，但缺点是每个客户端接入方式都不同。MCP Bridge 最大的价值，就是标准化。

3.3 学习环境与生产环境在方案上的差异

学习环境里，可以容忍密码简单、不加密、权限宽、日志全量输出。目标是快速跑通链路。生产环境则完全不同：

环境	SMB 账号	密码管理	网络暴露	日志
学习环境	直接用测试账号	写进`.env`即可	仅内网验证	全量输出方便排查
生产环境	最小权限专用账号	密钥管理工具，定期轮换	限制来源 IP	脱敏、保留、告警

如果一开始就在生产环境使用管理员账号和弱密码，风险会很大。建议先在学习环境跑通最小链路，再按生产要求加固。

4. 在 fnOS 上用 Docker 部署 SMB TO MCP Bridge

4.1 目录规划：应用目录、配置文件和日志目录分开

在 fnOS 的 Docker 数据目录下，创建项目目录：

/data/mcp-bridge/ ├── docker-compose.yml ├── .env └── logs/

目录分离的好处是，容器升级或重建时，配置文件和日志不会丢失。docker-compose.yml负责描述服务，.env负责保存环境变量，logs/用来挂载容器日志。

不建议把密码直接写在docker-compose.yml里。这样如果有一天有人把 compose 文件分享出来或提交到代码仓库，密码就会泄露。

4.2 编写 docker-compose.yml：容器化部署的骨架

下面是一个用于说明部署思路的 Compose 示例。实际部署时，镜像名、端口和变量名要以你确认过的项目文档为准：

services: smb-mcp-bridge: image: your-registry/smb-mcp-server:latest container_name: smb-mcp-bridge restart: unless-stopped env_file: - .env environment: TRANSPORT: "http" LISTEN_ADDR: "0.0.0.0" LISTEN_PORT: "8010" ports: - "8010:8010" volumes: - ./logs:/app/logs

这里解释几个关键点：

restart: unless-stopped让容器在 NAS 重启后自动恢复。
env_file从外部文件读取环境变量，避免把密码写进 compose 主文件。
LISTEN_ADDR: "0.0.0.0"表示容器内监听所有网络接口，这样外部客户端可以通过局域网 IP 访问。
ports把容器的 8010 端口映射到宿主机，供 MCP 客户端访问。

如果你的 fnOS 界面没有提供 Docker Compose 能力，也可以使用docker run方式部署，下面是一个等价示例：

docker run -d \ --name smb-mcp-bridge \ --env-file .env \ -p 8010:8010 \ -v ./logs:/app/logs \ your-registry/smb-mcp-server:latest

这里要说明，命令中的your-registry/smb-mcp-server:latest只是示例。MCP Bridge 相关的镜像有很多社区实现，安装前要确认镜像是否维护、是否支持 HTTP 传输方式、以及环境变量的命名是否一致。

4.3 用 .env 管理 SMB 连接参数，避免密码散落在配置里

创建一个.env文件，写入 SMB 连接参数：

SMB_HOST=192.168.1.10 SMB_PORT=445 SMB_USERNAME=mcp-bridge SMB_PASSWORD=your-password SMB_SHARE=smb-docs SMB_DOMAIN=

各参数含义如下：

SMB_HOST：fnOS 的局域网 IP。不要写成localhost。
SMB_PORT：SMB 服务默认端口是 445。
SMB_USERNAME：用于连接 SMB 的专用账号。
SMB_PASSWORD：账号密码。
SMB_SHARE：要暴露给 MCP 工具的共享名称。
SMB_DOMAIN：在没有域环境的家庭场景通常留空，企业域环境按需填写。

如果密码包含$、&、空格等特殊字符，不同容器对.env的解析规则不一致，建议先测试。也可以在.env中对该值加引号，但要注意有些镜像会把引号当成密码内容的一部分。最稳妥的办法是先把密码设成简单值验证链路，再改复杂密码。

4.4 启动容器并确认日志没有报错

执行以下命令启动：

cd /data/mcp-bridge docker compose pull docker compose up -d

启动后查看容器状态和日志：

docker ps | grep smb-mcp-bridge docker logs -f smb-mcp-bridge

预期日志应该出现类似“listening on 0.0.0.0:8010”或“SMB connection ok”的信息。不同的 MCP Server 实现日志格式不同，但至少应该能看出：

服务进程启动成功。
MCP 传输层开始监听端口。
如果有连接测试逻辑，SMB 连接成功。

如果日志里直接出现NT_STATUS_LOGON_FAILURE，不要继续配置客户端，先回第 2 章检查 SMB 账号和共享路径。如果容器退出，查看退出原因，常见的是端口被占用或环境变量缺失。

4.5 关键参数速查：SMB_HOST、SMB_SHARE 与传输方式

参数	含义	常见值	错误配置的表现
SMB_HOST	fnOS 的局域网 IP	192.168.1.10	连接超时、拒绝连接
SMB_PORT	SMB 服务端口	445	报端口不可达
SMB_USERNAME	专用 SMB 账号	mcp-bridge	登录失败
SMB_PASSWORD	账号密码	不推荐明文写死	登录失败
SMB_SHARE	SMB 共享名	smb-docs	返回共享不存在
TRANSPORT	MCP 传输方式	http / sse	客户端无法发现工具
LISTEN_PORT	MCP 服务监听端口	8010	客户端连接被拒

这里最容易被忽略的是SMB_SHARE和SMB_HOST。SMB_SHARE填的是共享名称，不是smb://...路径，也不是挂载点。写错一个字符，Bridge 启动可能没问题，但工具调用会一直返回目录不存在。

注意：MCP 客户端的访问地址是 Bridge 的地址，不是 NAS 的 SMB 地址。两者的端口、协议完全不同。

5. 把 Bridge 接入 Claude Desktop、Cline、Dify 等智能体客户端

5.1 MCP 客户端配置的共性：URL、传输方式和认证

无论使用哪个客户端，MCP 配置本质上都是回答几个问题：

MCP Server 叫什么名字。
通过什么传输方式访问。
服务地址是什么。
是否需要认证信息。

对于部署在 NAS 容器里的 MCP Bridge，通常填写http://192.168.1.10:8010/mcp这样的地址。192.168.1.10是 fnOS 的局域网 IP，8010是映射出来的端口，/mcp是 MCP 端点。具体端点路径以服务文档为准。

一个常见的排查点是：客户端跑在哪台机器，就要从哪台机器访问 Bridge 地址。如果客户端和 NAS 不在同一网段，还要先检查路由和防火墙。

5.2 Claude Desktop 与 Cline：以 mcpServers 方式接入

Claude Desktop 或 Cline 这类客户端，通常支持在配置文件中添加 MCP Server。配置思路如下：

{ "mcpServers": { "smb-bridge": { "url": "http://192.168.1.10:8010/mcp" } } }

这里的url要能由客户端所在机器访问。如果客户端和 NAS 在同一台机器上，可以用localhost，但更推荐直接写局域网 IP，方便以后迁移客户端。

Cline 这类编辑器插件一般有 MCP 管理界面。你可以在界面中选择“MCP Server”类型，填入名称和 URL，客户端会自动请求工具列表。配置完成后，工具列表里应该出现list_directories、list_files等工具。

5.3 Dify 添加本地 MCP 服务：HTTP 类型工具注册

Dify 的 Agent 或工作流里，可以在“工具”区域添加“本地 MCP 服务”。选择 HTTP 类型后，填入 Bridge 的访问地址，Dify 会先拉取工具清单，再让你选择哪些工具进入 Agent。

Dify 侧要注意两点：

Dify 服务器必须能够访问 NAS 的 8010 端口，不能填 Dify 容器内部地址。
工具注册后，如果 Dify 版本或 MCP 协议版本不匹配，可能拉不到工具列表，需要从协议兼容角度排查。

实际应用时，建议先只注册“列目录”和“读取文件”两个只读工具，减少智能体误操作写文件的风险。

5.4 工具注册成功后的预期效果与一次真实查询

工具注册成功后，MCP Client 的工具列表页会出现类似下面的工具：

list_directories
list_files
read_file

当用户输入“看看 SMB 共享目录下有哪些文件”时，智能体会调用list_files，传入路径/。Bridge 通过 SMB 读取共享目录后，返回类似下面的 JSON：

[ { "name": "docs", "type": "directory" }, { "name": "report.pdf", "type": "file", "size": 204800, "mtime": "2025-01-10T08:30:00Z" } ]

智能体再基于这个结果生成自然语言回答。到这里，一条完整的 MCP 链路就通了。

如果工具列表没有出现，优先检查第 5.1 节的三个要素：URL 是否可以从客户端访问、传输方式是否与 Bridge 一致、有没有认证头没有填。

6. 按链路验证与排查：从 SMB 连通到工具调用

6.1 分段验证链路：每一段都有独立的检查命令

链路越复杂，越要分段验证。推荐按下面顺序逐层检查：

第一步，验证 SMB 本身。

smbclient -L //192.168.1.10 -U mcp-bridge

第二步，验证 Bridge 容器状态。

docker ps | grep smb-mcp-bridge docker logs --tail 50 smb-mcp-bridge

第三步，验证端口和网络。

从客户端所在机器执行：

curl http://192.168.1.10:8010/mcp

很多 MCP 服务对GET /mcp不一定有响应，可以用curl -v观察是连接被拒还是返回响应。重点是确认网络通，而不是纠结响应内容。

第四步，在客户端内查看工具列表。这一步需要进入 MCP 客户端界面，查看工具是否注册成功。

第五步，实际调用一次只读工具，例如list_files，确认返回数据格式。

每一段通过后再进入下一段，能显著降低排查难度。

6.2 常见问题排查表：现象、原因、检查方式、解决方案

问题现象	常见原因	检查方式	处理建议
容器启动后立即退出	端口被占用或环境变量缺失	`docker logs`看启动错误	检查端口占用、补齐环境变量
日志报 SMB NT_STATUS_LOGON_FAILURE	账号密码错误	用 smbclient 验证同一账号	修正`.env`，重启容器
日志报共享不存在	SMB_SHARE 填写错误	用`smbclient -L`查看真实共享名	改为正确的共享名称
客户端连接不上 Bridge	网络不通或端口未映射	用`curl`从客户端访问端口	检查防火墙、端口映射、IP 地址
工具列表为空	传输方式不匹配	对比客户端配置与 Bridge 文档	统一为 HTTP 或 SSE
能列目录但读文件超时	文件过大或网络不稳定	复制一个小文件测试	检查网络质量，确认超时配置
中文文件名乱码	编码不一致	查看 Bridge 日志返回内容	设置 UTF-8 环境变量并重启
NAS 没有读写权限	SMB 目录权限不足	在 NAS 上检查共享权限和账号权限	给专用账号配置最小但足够的权限

6.3 几个反复出现的坑：容器 IP、特殊字符、协议版本与路径风格

第一个坑：在容器里访问宿主 NAS 时写了127.0.0.1。Docker bridge 网络下，127.0.0.1表示容器自身，而不是宿主机。要把SMB_HOST写成 fnOS 的局域网 IP，或者改用 host 网络。

第二个坑：SMB 密码含特殊字符。.env文件对#、$等字符的处理可能和 shell 不同。建议先用无特殊字符的密码跑通，再用安全方式处理复杂密码。

第三个坑：老系统访问 SMB 时的协议兼容问题。Windows 7 默认只能访问 SMB1，而现代 NAS 往往默认关闭 SMB1。如果严格要求“老系统也能访问”，不要在客户端重新打开 SMB1，因为风险很高，更好的方式是升级客户端或调整 NAS 允许的协议版本。

第四个坑：路径风格不一致。在 SMB 客户端里路径可能写\\192.168.1.10\smb-docs\folder，但 MCP 工具参数往往传/folder或空路径。要仔细看 MCP 工具的参数说明，确认路径是“共享内相对路径”还是“完整路径”。

6.4 可复用的排错顺序：从 SMB 到 MCP 逐层向后

遇到任何问题，都按照下面的优先级排查：

输入检查：账号、密码、共享名、路径是否写对。
文件路径和命名：共享名和目录是否存在。
容器配置：环境变量是否加载、镜像版本是否正确。
网络：客户端能否访问 Bridge 端口、Bridge 能否访问宿主机 445 端口。
协议：客户端与 Bridge 的 MCP 传输方式是否一致。
日志：容器日志和 MCP 客户端的日志是否出现明确异常。
版本限制：MCP 客户端版本与 Bridge 使用的 MCP 协议版本是否兼容。

这个顺序把“底层可访问性”放在前面，避免在协议和配置上反复兜圈子。

7. 生产化前要补上的权限、安全与发布清单

7.1 使用最小权限账号，严格限定可访问目录

无论 MCP Bridge 怎么封装，它最终都是用 SMB 账号去访问 NAS。如果这个账号对 NAS 所有共享都有读写权限，智能体就有能力读取甚至修改整个 NAS 上的文件。

建议：

为 Bridge 创建专用账号，归属独立用户组。
在共享文件夹权限中，只给 Bridge 需要的目录授权。
如果应用场景只是读取文件，只开只读权限。
定期检查该账号最近访问了哪些文件。

MCP 让智能体具备操作文件的能力，权限边界必须明确，这是生产化最重要的前提。

7.2 敏感信息、日志和镜像版本要纳入管理

不要把账号密码写进代码仓库。.env文件要加入.gitignore。生产环境可以使用 Docker Secrets 或密钥管理工具注入环境变量，密码要定期轮换。

日志方面，MCP Bridge 的日志可能会记录路径、文件名、返回内容。建议在日志中脱敏账号信息，并且对日志设置保留周期。镜像版本要固定，不要长期使用latest，否则镜像更新可能带来不兼容变更。

7.3 控制网络暴露面，不建议公网映射

MCP Bridge 监听0.0.0.0是为了让局域网内的多个客户端都能访问，但这不等于要把服务直接暴露到公网。不建议在路由器上同时把 NAS 的 445 端口和 Bridge 的 8010 端口做公网映射。如果确实需要外网访问，应该走成熟的安全方案，而不是直接在公网裸奔。

在局域网内部，也可以按需做访问控制：

通过防火墙限制只有特定客户端 IP 能访问 8010。
把 Bridge 容器放在独立的 Docker 网络里。
不为不需要写操作的场景开放上传类工具。

安全的原则是：暴露越少，风险越低。

7.4 发布前检查清单与生产化扩展方向

下面是一份可以直接对着用的发布前检查清单：

SMB 共享名、路径、账号、权限已经确认。
使用专用账号，不是管理员账号。
SMB 445 端口从 Bridge 容器能访问。
镜像版本固定，不是latest。
.env没有入库，密码没有写在 compose 文件里。
Bridge 容器启动了，日志中没有 SMB 认证错误。
MCP 客户端能够发现工具列表。
使用只读工具完成了一次真实调用。
客户端所在机器能访问 Bridge 端口。
没有把 445 和 8010 端口直接映射到公网。
日志保留策略和告警已配置。

扩展方向上，后续可以做三件事：一是增加文件类型过滤，让 MCP 工具只暴露文档、日志、图片等指定格式；二是增加操作审计，记录每一次工具调用来自哪个客户端、操作了什么路径；三是把 SMB 只读账号收窄到只读权限，再把 Bridge 接入 Agent 编排流程，让智能体在指定目录中自动整理会议记录、分析日志或生成报表。

部署一个 SMB TO MCP Bridge，本质不是把镜像跑起来，而是让链路里的每一段都明确：SMB 共享可访问、Bridge 能连接、客户端能发现工具、工具调用能返回结果。先把最小链路验证通过，再从只读扩展到写操作，最后逐步加固账号权限和网络安全，这套方案就能稳定地进入日常使用。