我们最近安装了一个 GPS 基站，它是一种高精度 GPS 接收器，用于现场 GPS 设备的误差校正。该设备（Trimble NetR9）使用嵌入式 Linux 操作系统，并将数据文件通过 FTP 传输到另一台 FTP 服务器（在我的情况下是带有 IIS 的 Windows 2012 服务器）。该设备能够在 FTP 服务器上创建目录，但无法推送文件。
我想知道我是否忽略了 FTP 服务器（Win 2012）上的某些设置，以使其对 Linux 客户端友好？
已尝试的测试：
权限：为了消除权限设置错误的可能性，我为用户提供了对 ftproot 文件夹及其所有子文件夹的完全读/写权限，并尝试以管理员用户身份登录。此用户的 IIS 设置也显示“读”和“写”。上述两个结果仍然可见。我还测试了使用同一用户从工作站到 FTP 服务器执行相同的 FTP 过程，并且没有出现文件上传问题。
网络电缆： 为了排除网络布线可能存在问题（可能性非常小），我们使用 Fluke 网络测试工具测试了从交换机到 NetR9 的所有布线，没有发现任何问题。
防火墙、路由器、NAT等： 为了消除某些防火墙规则或路由器配置的可能性，我为 Windows Surface 平板电脑配置了与 NetR9 完全相同的 TCP/IP 设置，拔下 NetR9 的数据插孔，并将 Surface 插入同一插孔。因此，Surface 从 TCP/IP 角度模拟了 NetR9。从 Surface 上使用 FTP，使用相同的凭据将文件放到同一个 FTP 服务器上没有任何问题。
被动/主动：为了排除其中一种 FTP 方法比另一种效果更好的可能性，我在设备上尝试了所有 3 种 FTP 方法，但结果没有差异。
Windows 防火墙： 我们检查后发现，在我们开始任何操作之前，这台服务器上的 Windows 防火墙确实已关闭。我们将其关闭。
Windows 服务器： 为了消除我的 Windows 2012 Server 上的 IIS 配置可能存在问题的可能性，我们在具有 IIS 的旧版 Windows 2008 Server 上复制了 FTP 服务器设置，并得到了完全相同的结果。
日志文件摘录 这是每次从设备向 Widnows 服务器进行 FTP 推送后在日志文件中发现的内容。您可以看到它正在创建文件夹，但最后一部分（推送文件 laco209x.T02）不起作用。
2016-07-28 00:00:02 - - - 21 控制通道打开 - - 0 0 0 0 0 - -
2016-07-28 00:00:02 - FTPSVC2 - 21 用户 331 0 0 23 14 0 - -
2016-07-28 00:00:02 \ FTPSVC2 - 21 通过 *** 230 0 0 21 18 0 / -
2016-07-28 00:00:02 \ FTPSVC2 - 21 CWD t02/ 250 0 0 29 10 0 /t02 -
2016-07-28 00:00:02 \ FTPSVC2 - 21 CWD 2016/ 250 0 0 29 11 16 /t02/2016 -
2016-07-28 00:00:02 \ FTPSVC2 - 21 CWD 209/ 250 0 0 29 10 0 /t02/2016/209 -
2016-07-28 00:00:02 \ FTPSVC2 - 21 CWD LACO/ 250 0 0 29 11 0 /t02/2016/209/LACO -
2016-07-28 00:00:02 \ FTPSVC2 - 21 类型 I 200 0 0 20 8 0 - -
2016-07-28 00:00:02 \ FTPSVC2 - 21 端口 10,40,55,108,234,136 200 0 0 30 27 0 - -
2016-07-28 00:00:03 \ FTPSVC2 - 21 STOR laco209x.T02 550 4294967295 0 48 19 1031 /t02/2016/209/LACO/laco209x.T02 -
2016-07-28 00:00:04 \ FTPSVC2 - 21 类型 I 200 0 0 20 8 0 - -
2016-07-28 00:00:04 \ FTPSVC2 - 21 退出 - 221 0 0 14 6 0 - -
2016-07-28 00:00:04 \ FTPSVC2 - 21 控制通道关闭 - - 0 0 319 142 2218 - -
我也在与供应商探讨这个问题，但想在这里问一下，以防有人看到过 Linux FTP 客户端和 Windows FTP 服务器之间类似的行为。