Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've got an OpenIndiana server running ZFS that is shared using a nobody user and group. I don't fully understand Solaris ACL permissions, but I do know Linux style permissions. The client is Windows 8 and the server is OpenIndiana is oi_148.

I'm failing to work out how to make write permission work correctly for the Windows client. It is able to make new files, but can not modify files created by the shell in OpenIndiana.

When a file ("local file") is created locally as the user nobody in bash, and another file ("smb file") created remotely via SMB (as nobody also), they are quite different in permissions:

# ls -V
-rw-r--r--   1 nobody   nobody         0 Dec  2 12:24 local file

-rwx------+  1 nobody   nobody         0 Dec  2 12:24 smb file

In bash, I'm able to write to smb file, but vice versa, the Windows client is not able to write to local file. This is confusing to me because it appears that it should allow the SMB client to write to local file, because nobody is the owner and it has a w in the ACL.

The sharesmb setting is is fairly boring, although I'm hoping there can something to set in here similar to a umask:

sharesmb name=shared,guestok=true

How can I make these two work together and have a symmetrical permission system, where both SMB and the local user produce the same permissions?

Is there some sort of ACL that can set at the root of the file system to allow all files to be created in a similar manner?

share|improve this question

migrated from Dec 2 '12 at 14:36

This question came from our site for computer enthusiasts and power users.

I think there is confusion on whether networking questions belong on ServerFault because its name (and I believe its original definition) doesn’t match its current scope. – Synetech Dec 2 '12 at 6:10
up vote 1 down vote accepted

There were a few problems with my set up:

  • The ACL created by the local user didn't have d and D flags set which means it can't be deleted/moved, although I still don't understand why the local user was able to delete it when SMB was not able to.
  • The ACL's weren't set in a way so that ACL's would be inherited, i.e. the fd flags.
  • ZFS aclinherit property should be set to passthrough instead of restricted.


# chmod A=owner@:rwxpdDaARWcCos:fd:allow /z/shared
# zfs set aclinherit=passthrough z/shared

After creating files from SMB and locally:

$ ls -V
total 2
-rwx------+  1 nobody   nobody         0 Dec  8 00:17 local
-rwx------+  1 nobody   nobody         0 Dec  8 00:17 smb

Note the I which shows that the ACL is inherited.

The ZFS settings are described in the ZFS administration guide:

restricted – For new objects, the write_owner and write_acl permissions are removed when an ACL entry is inherited.

passthrough – When property value is set to passthrough, files are created with a mode determined by the inheritable ACEs. If no inheritable ACEs exist that affect the mode, then the mode is set in accordance to the requested mode from the application.

Now the SMB client is able to delete files created locally.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.