这是一个创建于 2348 天前的主题，其中的信息可能已经有所发展或是发生改变。
刚刚发现昨天传到服务器的脚本没有按时执行，看日志发现是 Permission denied。
又一次给自己吃药。
所以想问一下，windows 和 linux 之间相互传文件，不同的传递方式，权限是如何传递的？
比如，复制粘贴？ FTP ？
我昨天这个脚本是同事邮件发给我，然后我通过 windows 环境复制粘贴到堡垒机，堡垒机 FTP 到生产环境。
到生产环境就变成 644 了。这个脚本在同事那边肯定是有 x 权限的。只是我不清楚具体是哪一步把这个权限抹掉了。
欢迎大神指点，大家讨论
又一次给自己吃药。
所以想问一下，windows 和 linux 之间相互传文件，不同的传递方式，权限是如何传递的？
比如，复制粘贴？ FTP ？
我昨天这个脚本是同事邮件发给我，然后我通过 windows 环境复制粘贴到堡垒机，堡垒机 FTP 到生产环境。
到生产环境就变成 644 了。这个脚本在同事那边肯定是有 x 权限的。只是我不清楚具体是哪一步把这个权限抹掉了。
欢迎大神指点，大家讨论
 |
1
zarte 2018-06-20 09:49:14 +08:00
堡垒机 sftp 传可行不？
|
 |
2
lcdxiangzi OP @zarte 刚刚我没有说清楚，看了一下，我是用 sftp 上传的。
那就是另一个问题，SFTP 和 FTP 上传方式，有不同的地方吗？在文件权限方面 |
 |
3
E1n 2018-06-20 09:59:54 +08:00  1
umask 问题吧
|
|
4
lcdxiangzi OP @E1n 我验证了一下，目前看下来是和 umask 一致的。多谢指点，学习了
|
 |
5
Judoon 2018-06-20 14:13:49 +08:00 via Android
如果 windows 本地转存过应该是不行的，毕竟文件系统不存权限这类元信息，所以要无逢体验，用 linux 或 mac。除非你同事打包然后你不解压，传到目标机器再解
|
 |
6
ShineSmile 2018-06-20 14:15:58 +08:00
是不是行尾 CRLF 的问题啊
|
|
7
ShineSmile 2018-06-20 14:25:22 +08:00
在 windows 环境下写的脚本保存时行尾用 LF 而不是 CRLF 试一下。
刚刚 CRLF 保存 scp 上去提示 permission denied。 换成 LF 好了。 |
|
8
lcdxiangzi OP @Judoon 先从 LINUX 到 windows，然后再到 linux。这个过程中权限是不是已经丢掉了。我觉得这个是可以讨论的。当然解压、打包之类的也可以讨论。
|
|
9
lcdxiangzi OP @ShineSmile 这个还不是很了解，我要看一下呢。
不过刚刚我按照 #3 的提示，看了一下，我昨天在两个不同服务器上上传了脚本，刚好两个不同服务器的 umask 不一致。上传后得到的权限是分别和各自的 umask 匹配的呢。所以我以为这个问题就是 umask 导致的。 理论上讲，你和#3 应该只可能有一个人是对的 |
|
11
ShineSmile 2018-06-20 17:39:21 +08:00
自己 Linux 也不是很精通，抱着学习的态度讨论一下。
CRLF 保存的时候注意一下就好。可能不是问题的根本。 umask 我学习一下。 |
|
13
Judoon 2018-06-21 00:04:35 +08:00 via Android
@lcdxiangzi 如果没有打过包，肯定丢失，你试试就行。我说了，文件系统问题。
|
|
15
Judoon 2018-06-21 00:23:41 +08:00 via Android
楼上说 umask 的，并不是根本原因。
可以动手试试把 ntfs 或者 fat 类的文件系统挂载到 linux 系统下，然后对里面的文件做 chown,chmod 等权限操作，永远无效 所以根本原因是文件系统没有存储这类权限相关的信息，导致在复制到目标 linux 服务器时，linux 根据系统默认的 umask 为创建的文件添加了权限类信息 |
 |
16
geelaw 2018-06-21 01:09:17 +08:00 via iPhone 1
@Judoon NTFS 不能，因为 Linux 不使用 Windows SID，然而对应的概念（执行权限）是存在的。
权限的丢失发生在共享协议上，共享协议层可以进行 owner/group/mode 映射，然而看起来它只进行了文件的字节传输。最简单的映射方法是计算 NTFS 上改对象 owner 的权限并设置为新文件的 owner/group 权限，计算 Everyone 的权限并设置为新文件的 other 权限，令新文件的 owner/group 为粘贴者的 owner/group。 此外，在不同的 Unix/Linux 机器之间传输，权限也是需要映射的，两者不非要有相同的用户和组，单纯迁移八位掩码会因为 owner 和 group 的改变出现意想不到的结果。通常做法是照抄掩码并改变 owner/group 为粘贴者。我不知道用了目录服务的机器会怎么样（是否会有相同的 UID - 用户名 对应关系之类的）。 |
|
17
lcdxiangzi OP 大家都好专业，到后面我已经跟不上大家的节奏了，等下好好学习一下相关概念。
多谢各位指点，@Judoon @geelaw @E1n 总结一下，大家帮忙看看是否理解正确 1、ftp、sftp、复制、粘贴、打包、解压等操作本身是不会影响权限传递的。 2、上述几个操作的两端的文件系统会影响权限的变动，主要是看对端的文件系统是否可以承接映射后的权限信息。 3、因为 linux 和 windows （包括 mac，没用过，不是很了解）下都存在多种多样的文件系统，各自对彼此的文件系统的支持程度也是参差不齐的。所以在 1 中的操作过程中很可能会导致文件的某些附属属性发送改变或丢失，丢失后便会根据对端的系统生成默认的属性。 4、从单纯解决问题的角度，我觉得 @kaneg 的建议还是比较靠谱的。至少能规避到权限变动的问题。 综上，如有问题，欢迎继续讨论，谢谢 |
 |
18
raysonx 2018-06-21 10:57:27 +08:00 via Android
权限本身不是文件的一部分，而是存在文件系统中的。
所谓的保存权限信息，只不过是相应的软件做了特殊处理而已。楼主的案例中，用邮件发文件这一步权限就丢失了，因为邮件中没有额外保存权限信息。除非楼主能发明一个协议，在邮件中以某种格式保存权限信息，接收方的客户端能识别这些信息并依此在接受方创建文件。 |
Select Language