如何设置创build的目录和文件的默认值为775？ 我的理解是，我需要修改VSFTPD的umask，但我怎么知道要改变它呢？
我有一个http守护进程服务器进程（yaws），我想让服务器写入任何具有002的umask的新文件，以便同一组中的另一个用户可以修改，移动或删除由守护进程创build的文件。 这是在Ubuntu 10.04。 与Apache不同的是，yaws没有umask的configuration选项，那么有什么方法可以设置任何守护进程的umask？ 我find了有关更改init脚本添加umask 002 答案 。 这确实奏效，但我不确定编辑初始化脚本是使这个在多台机器上进行文档和configuration变得容易的最佳方式。 我也在这里find了对pam_umask模块的引用。 看起来像这样允许每个用户在/ etc / passwd的GECOS字段中configurationumask的设置。 有没有其他方法来设置守护进程的umask？ 那么推荐的方法是什么？
假设我的umask是0077。 我有一个目录foo ，我想要对其应用特殊权限。 我在foo创build的所有文件应该是世界可读的，所有的目录应该是世界可读和可执行的。 目前，如果我创build一个文件，它将是0600，目录将是0700： $ cd foo/ $ touch file $ mkdir directory $ ls -l drwx—— 2 nfm nfm 4096 2012-01-12 16:16 directory -rw——- 1 nfm nfm 0 2012-01-12 16:15 file 我想要的文件是0644和目录0755，无论我的umask： drwxr-xr-x 2 nfm nfm 4096 2012-01-12 16:16 directory -rw-r–r– 1 nfm nfm 0 2012-01-12 16:15 file 我怎样才能做到这一点？
//更新2月8日 – 突出问题简述： 如何umask目录不同于文件？ 如何掩饰鹦鹉螺复制/粘贴？ 如何为SSHFS设置umask？ 我们的情况 我们公司的几个人login到服务器并上传文件。 他们都需要能够上传和覆盖相同的文件。 他们有不同的用户名，但都是同一组的一部分。 但是，这是一个互联网服务器，所以“其他”用户应该（一般来说）只读访问。 所以我想要的是这些标准的权限： 文件：664 目录：771 我的目标是所有用户不需要担心权限。 服务器的configuration方式应使这些权限适用于新创build，复制或覆盖的所有文件和目录。 只有当我们需要一些特殊的权限，我们会手动改变这一点。 我们通过Nautilus中的SFTP将file upload到服务器，通过使用sshfs挂载服务器并在Nautilus中像访问本地文件夹一样访问它，并通过命令行中的SCP进行访问。 这基本上涵盖了我们的情况和我们的目标。 现在，我读了许多关于美丽的umaskfunction的东西。 从我所了解的umask（和PAM一起） 应该让我做到我想要的：为新的文件和目录设置标准的权限。 但是，经过了许多个小时的阅读和反复试验，我仍然没有得到这个工作。 我得到许多意想不到的结果 我真的很想搞好umask，还有很多问题没有答案。 我将在下面发表这些问题，以及我的调查结果和对导致这些问题的试验的解释。 鉴于很多事情似乎出了问题，我认为我做了几件事情是错误的。 因此，有很多问题。 注：我使用的是Ubuntu 9.10，因此无法更改sshd_config以设置SFTP服务器的umask。 已安装SSH OpenSSH_5.1p1 Debian-6ubuntu2 <必需OpenSSH 5.4p1。 所以在这里去回答问题。 1.我是否需要重新启动PAM CHANGS才能生效？ 我们先从这个开始。 有太多的文件涉及，我无法弄清楚什么是什么，什么不影响事情，也因为我不知道是否必须重新启动整个系统PAM更改才能生效。 在没有看到预期的结果之后，我确实这样做了，但这真的有必要吗？ 或者我可以从服务器注销并重新login，并且新的PAM策略是否有效？ 还是有一些“PAM”程序来重新加载？ 2.是否有一个单一的文件改变，影响所有会议的所有用户？ 所以我最终改变了许多文件，因为我读了很多不同的东西。 我结束了在以下文件中设置umask： ~/.profile -> umask=0002 ~/.bashrc -> umask=0002 /etc/profile -> […]
我知道这个问题已经讨论过了，但是通过阅读post，我找不到答案，因为有些人说“是的，umask可以工作”，还有人说“OpenSSH put命令总是保留权限” 以前只是为了精确： 我在RHEL 6.2上使用OpenSSH 5.9 我已经使用internal-sftp子系统configuration了一个chroot的SFTP服务器，使用-u 0002作为umask 我确切地说我不使用-p或-P选项 从我读过的一方面来说：有许多方法可以为SFTP传输定义umask： 从OpenSSH 5.4开始，selectinternal-sftp （或者sftp-server ）的-u选项 创build一个封装到sftp-server （我们明确地设置了Umask – 这不适合chrooted环境BTW） 在pam.d/sshd文件中添加一个特定的configuration 另一方面，我读到： OpenSSH SFTP客户端和服务器确实传输权限（作为扩展名），并在本地创build具有权限的远程文件。 AFAICT，没有办法禁用这种行为。 所以我做了以下testing： 在我的客户端上，我创build了具有权限600和700的文件MYFILE和目录MYDIR 。 然后用sftp命令： mkdir => the new directory has permissions following the umask (OK) put MYFILE => MYFILE has same permissions as on client (KO) put -r MYDIR => MYDIR has […]
我有一个特定的目录，有一个项目由多个用户共享。 这些用户使用SSH访问此目录并修改/创build文件。 这个项目只能写给一个用户群：让我们称之为“mygroup”。 在SSH会话期间，由当前用户创build的所有文件/目录应默认为组“mygroup”拥有，并具有组可写权限。 我可以用umask解决权限问题： $ cd project $ umask 002 $ touch test.txt 文件“test.txt”现在是可写组的，但仍属于我的默认组（“mislav”，与我的用户名相同），而不属于“mygroup”。 我可以recursionchgrp来设置所需的组，但我想知道是否有一种方法来隐式设置一些组，像umask更改会话期间的默认权限。 这个特定的目录是一个工作副本的共享git仓库，我希望git checkout和git reset操作为在工作副本中创build的新文件设置正确的掩码和组。 操作系统是Ubuntu Linux。 更新：一位同事build议我应该研究POSIX ACL的 getfacl / setfacl，但是在当前会话中，下面的解决scheme与umask 002结合起来对我来说是足够好的，而且更简单。
我需要由apache2创build的文件默认情况下有umask 002 ，即组rw。 我试过把umask 002放在/ etc / apache2 / envvars中，虽然这个脚本是作为apache启动的一部分执行的（ apache2ctl graceful ），但umask没有任何作用。 大概在启动过程的某个地方（例如，当用户从root降级到www-data ），还有一个更好的地方。 我已经阅读了关于Fedora的文章，并且build议将umask放在/etc/init.d/apache2但是这些文件都不适用于Debian（Squeeze）。 你能帮我吗？
我们有一个Ubuntu 10.04服务器。 如何设置它，以便通过SFTP或SSH创build（或复制）的新文件具有g + rw和g + rwx权限（在适当情况下）？ 我还使用setgid（chmod g + s），以便它们inheritance适当的组所有者。
我一直在寻找一种方式来设置OpenSSH的umask到所有连接types一致的方式0027 。 我指的是连接types： SFTP SCP ssh主机名 SSH主机名程序 3.和4.之间的区别在于前者启动一个通常读取/etc/profile信息的shell，而后者则不会。 另外通过阅读这篇文章，我已经意识到在OpenSSH的新版本中存在的-u选项。 但是这不起作用。 我还必须补充说/etc/profile现在包含了umask 0027 。 逐点进行： sftp – 如上所述，在sshd_config设置-u 0027是不够的。 如果我不设置这个参数，sftp默认使用umask 0022 。 这意味着如果我有两个文件： -rwxrwxrwx 1 user user 0 2011-01-29 02:04 execute -rw-rw-rw- 1 user user 0 2011-01-29 02:04 read-write 当我使用sftp把它们放到目标机器时，我实际上得到： -rwxr-xr-x 1 user user 0 2011-01-29 02:04 execute -rw-r–r– 1 user user 0 2011-01-29 02:04 read-write […]