刚刚发现昨天传到服务器的脚本没有按时执行，看日志发现是 Permission denied。
又一次给自己吃药。
所以想问一下，windows 和 linux 之间相互传文件，不同的传递方式，权限是如何传递的？
比如，复制粘贴？ FTP ？

我昨天这个脚本是同事邮件发给我，然后我通过 windows 环境复制粘贴到堡垒机，堡垒机 FTP 到生产环境。
到生产环境就变成 644 了。这个脚本在同事那边肯定是有 x 权限的。只是我不清楚具体是哪一步把这个权限抹掉了。
欢迎大神指点，大家讨论
堡垒机 sftp 传可行不？

刚刚我没有说清楚，看了一下，我是用 sftp 上传的。
那就是另一个问题，SFTP 和 FTP 上传方式，有不同的地方吗？在文件权限方面

umask 问题吧

我验证了一下，目前看下来是和 umask 一致的。多谢指点，学习了

如果 windows 本地转存过应该是不行的，毕竟文件系统不存权限这类元信息，所以要无逢体验，用 linux 或 mac。除非你同事打包然后你不解压，传到目标机器再解

是不是行尾 CRLF 的问题啊

在 windows 环境下写的脚本保存时行尾用 LF 而不是 CRLF 试一下。
刚刚 CRLF 保存 scp 上去提示 permission denied。
换成 LF 好了。

先从 LINUX 到 windows，然后再到 linux。这个过程中权限是不是已经丢掉了。我觉得这个是可以讨论的。当然解压、打包之类的也可以讨论。

这个还不是很了解，我要看一下呢。
不过刚刚我按照 的提示，看了一下，我昨天在两个不同服务器上上传了脚本，刚好两个不同服务器的 umask 不一致。上传后得到的权限是分别和各自的 umask 匹配的呢。所以我以为这个问题就是 umask 导致的。
理论上讲，你和应该只可能有一个人是对的

用 sh xxx.sh 可以避免权限问题。

自己 Linux 也不是很精通，抱着学习的态度讨论一下。
CRLF 保存的时候注意一下就好。可能不是问题的根本。
umask 我学习一下。

你还在用 FAT ？

如果没有打过包，肯定丢失，你试试就行。我说了，文件系统问题。

说得好像 NTFS 可以存储 linux 的文件权限元数据信息一样

楼上说 umask 的，并不是根本原因。
可以动手试试把 ntfs 或者 fat 类的文件系统挂载到 linux 系统下，然后对里面的文件做 chown,chmod 等权限操作，永远无效
所以根本原因是文件系统没有存储这类权限相关的信息，导致在复制到目标 linux 服务器时，linux 根据系统默认的 umask 为创建的文件添加了权限类信息

NTFS 不能，因为 Linux 不使用 Windows SID，然而对应的概念（执行权限）是存在的。
权限的丢失发生在共享协议上，共享协议层可以进行 owner/group/mode 映射，然而看起来它只进行了文件的字节传输。最简单的映射方法是计算 NTFS 上改对象 owner 的权限并设置为新文件的 owner/group 权限，计算 Everyone 的权限并设置为新文件的 other 权限，令新文件的 owner/group 为粘贴者的 owner/group。
此外，在不同的 Unix/Linux 机器之间传输，权限也是需要映射的，两者不非要有相同的用户和组，单纯迁移八位掩码会因为 owner 和 group 的改变出现意想不到的结果。通常做法是照抄掩码并改变 owner/group 为粘贴者。我不知道用了目录服务的机器会怎么样（是否会有相同的 UID - 用户名 对应关系之类的）。

大家都好专业，到后面我已经跟不上大家的节奏了，等下好好学习一下相关概念。
多谢各位指点，@Judoon
总结一下，大家帮忙看看是否理解正确
1、ftp、sftp、复制、粘贴、打包、解压等操作本身是不会影响权限传递的。
2、上述几个操作的两端的文件系统会影响权限的变动，主要是看对端的文件系统是否可以承接映射后的权限信息。
3、因为 linux 和 windows （包括 mac，没用过，不是很了解）下都存在多种多样的文件系统，各自对彼此的文件系统的支持程度也是参差不齐的。所以在 1 中的操作过程中很可能会导致文件的某些附属属性发送改变或丢失，丢失后便会根据对端的系统生成默认的属性。
4、从单纯解决问题的角度，我觉得 的建议还是比较靠谱的。至少能规避到权限变动的问题。
综上，如有问题，欢迎继续讨论，谢谢

权限本身不是文件的一部分，而是存在文件系统中的。
所谓的保存权限信息，只不过是相应的软件做了特殊处理而已。楼主的案例中，用邮件发文件这一步权限就丢失了，因为邮件中没有额外保存权限信息。除非楼主能发明一个协议，在邮件中以某种格式保存权限信息，接收方的客户端能识别这些信息并依此在接受方创建文件。