create and delete here is based on directory permissions.

edit is presumably based on file permissions.

That said, generally speaking, windows permissions are incredibly
complex and (as a result) mostly ignored. [There will be a few people
who will deny this, but as a general rule most people denying this
complexity cannot even enumerate from memory all the windows
permission options.] So, usual practice is to leave permissions wide
open. You'll probably need to emulate something like that here, to
meet expectations of windows users.

-- 
Raul


On Mon, Jun 12, 2017 at 11:38 AM, Rupert Gallagher <r...@protonmail.com> wrote:
> Context:
>
> A windows 10 pro client connects to openbsd nfs shared folder using username 
> and password on the openbsd system.
>
> /etc/exports contains
> /exports/Shared -mapall=nobody:shared [client-ip]
>
> permissions:
> drwxr-xr-x root wheel exports/
> drwxrwxr-x nobody staff exports/Shared/
>
> user is a member of group "staff"
>
> Note:
>
> If I remove the above mapall,
> when the user creates a new file, its uid is 4294967294.
>
> Problem 1:
> When the user creates a new text file (.txt), its permissions are 
> automatically set to -rwxr-xr-x nobody:staff. The execute permission on 
> non-executable files is a windows umask problem that I have never managed to 
> fix.
>
> Problem 2:
> The user can delete a file I created myself with the following permissions:
>
> -rw-r--r-- root:staff. test.txt
>
> Problem 3:
> The user can create and delete a dummy test file, but cannot edit the same: 
> windows says the file is read only! The unix permissions are -rwxr-xr-x 
> nobody:staff, the windows 10 nfs attributes are the same, but the windows 
> general attributes for the same file say the file is read only.
>
> I am going nuts...
>
> Sent from ProtonMail Mobile

Reply via email to