I think the problem is how windows mounts the nfs folder by default (right click on "this computer" then select to attach a network folder to a drive letter). The following article by Microsoft describes the mount option "fileaccess" to set a default umask:
https://technet.microsoft.com/en-us/library/cc754350(v=ws.11).aspx This option is not available from the default menu. Sent from ProtonMail Mobile On Mon, Jun 12, 2017 at 7:24 PM, Raul Miller <rauldmil...@gmail.com> wrote: p.s. if you do not want windows files in that shared directory to be executable, I think you can mount the nfs backing store partition noexec. I haven't tested this, though - I mostly try to avoid networked file systems. Thanks, -- Raul On Mon, Jun 12, 2017 at 1:22 PM, Raul Miller <rauldmil...@gmail.com> wrote: > Ok, look... > > Your problem 1: all windows files are executable because the windows > model for executable or not is proprietary and not supportable. It's > also not clear why you should care about this in a shared directory. > > Your problem 2: if we assume that a shared directory (rather than user > specific directories) is the right approach, and if we also assume > that each user's claim to a file name should deny write access to > other users with that file name, we need to look at the permissions on > the containing directory. > > In your case, you have drwxrwxr-x -- this means that everyone who is a > member of the staff directory has the right to remove directory > entries. If you do not want that, you need to change the permissions > on the directory: http://man.openbsd.org/sticky.8 > > But, note that if you are changing the owner on the files to not match > that of the user who created the files, you should expect that people > will not be able to delete files that they themselves created. > > Your problem 3: this is a consequence of your having changed the owner > of the file. Your file permissions say that only the owner can change > the file. > > With this in mind, I think I can see how I would change things to > match what you seem to be claiming that you want: > > (1) remove the user id mapping > > (2) set the sticky bit on the Shared directory. > > If you do not want this, I think you need to spend a little time > thinking about what it is that you actually want, and whether or not > that should even be possible. > > (So far, you have only mentioned an example uid value for a user as > perhaps being an issue. This, combined with the subject line in this > thread are the only clues I have as to why you might not have removed > the user id mapping. But why this should even be an issue for you is > unclear to me.) > > Thanks, > > -- > Raul > > > On Mon, Jun 12, 2017 at 12:58 PM, Rupert Gallagher <r...@protonmail.com> > wrote: >> On problem 2, >> >> if a user has group write permission on a folder, it has permission to write >> its own files and those of same group membership in that folder, provided >> the group permission is set on the file by its owner. If a file belongs to >> me and I deny write permission to group and other, then nobody can write my >> file. File creation and destruction are forms of writing. This is what I am >> used to see. The ability of a windows nfs user to delete a file for which it >> has no write permission is a security
