遇到这种常规工具都抓不到对应进程的情况确实挺闹心的，结合你提到的是Docker容器挂载SMB共享的场景，我给你几个针对性的排查方向：

• 先试试fuser工具，它在处理端口关联进程时有时候能挖到ss/lsof漏掉的线索，执行这条命令：

  fuser -v 43482/tcp
  

  它会直接列出占用这个TCP端口的进程PID、用户和命令，很直观。

• 既然是给Docker容器挂载的SMB共享，大概率是容器内部的进程在占用这个连接。先定位到使用对应SMB挂载路径的容器：

  docker ps --format "{{.ID}}: {{.Mounts}}" | grep "你的SMB挂载路径"
  

  找到容器ID后，要么直接查看容器内的进程列表：

  docker top <容器ID>
  

  要么进入容器内部用工具排查（容器里可能需要先安装netstat/lsof）：

  docker exec -it <容器ID> bash
  ss -tunarp | grep 445  # 容器内看到的是连接到SMB的445端口
  

• 从内核层面挖连接细节，直接读取/proc/net/tcp文件：
  首先把你的本地端口43482转换成十六进制：

  printf "%x\n" 43482
  

  得到十六进制值后（比如43482对应0xA9DA），搜索这个值找到对应的连接条目：

  grep 0xA9DA /proc/net/tcp
  

  输出里的第10列是该连接的inode编号，接着用这个inode找关联进程：

  find /proc -name fd -type d | xargs ls -l | grep "<刚才得到的inode值>"
  

  结果里会显示进程的PID和对应的文件描述符，你再通过ps aux | grep <PID>就能查到进程命令了。

• 如果上面的方法都没结果，试试用bpftrace从内核层面追踪连接行为。先安装bpftrace，然后运行这个脚本：

  bpftrace -e 'tracepoint:syscalls:sys_enter_connect { printf("PID: %d, Comm: %s, Dst Port: %d\n", pid, comm, args->uservaddr->sin_port >> 8); }'
  

  这个脚本会实时打印所有发起网络连接的进程信息，等你看到目标端口是445的条目，就能直接拿到对应的PID和命令名了。

备注：内容来源于stack exchange，提问作者crackpot