samba - Apr 2010 - viewing, if not editing, NFSv4 ACL's from Samba shares

Good morning, folks.

I'm involved in a project to enforce NFSv4 ACL's across a variety of
storage platforms, in particular NetApps sharing NFS. That works fiine
with the NetApp NFS qtrees, but we'd like to share those with CIFS
clients as well. This works, and restricts access the way we expect
NFSv4 ACL's to work, but the Windows clients cannot view any of the
security settings on the directories or files.

Cue the music, and enter Samba 3.5.2. I've reviewed various public
notes on how to use NFSv4 ACL's on recent Samba (particularly those at
http://www.sambaxp.org/files/SambaXP2009-DATA/Nils_Goroll.pdf), and
installed Samba 3.5.2 on test servers. And I've set up shares with the
following settings.

[share]
acl check permissions = False
ea support = yes
store dos attributes = yes
map readonly = no
map archive = no
map system = no
vfs objects = zfsacl
nfs4: mode = special
nfs4: acedup = merge

The "map readonly" is rejected, and I'm not sure why.
The vfs objects seems to have no effect for NFSv4 access. NFSv4
permissions do seem to be followed.

But Windows clients still can't see any of the security settings under
the "Security" tab of properties.

And really, really unfortunately, the NetApp ".snapshot" directories
are showing up by default. That's deadly: directory copy operations
may attempt to include the .snapshot backup targets, and that would
*really* get nutty.

On Tue, Apr 20, 2010 at 07:45:00AM -0400, Nico Kadel-Garcia
wrote:
> I'm involved in a project to enforce NFSv4 ACL's across a variety
of
> storage platforms, in particular NetApps sharing NFS. That works fiine
> with the NetApp NFS qtrees, but we'd like to share those with CIFS
> clients as well. This works, and restricts access the way we expect
> NFSv4 ACL's to work, but the Windows clients cannot view any of the
> security settings on the directories or files.
The NetApp CIFS server should allow that, doesn't it?
> Cue the music, and enter Samba 3.5.2. I've reviewed various public
> notes on how to use NFSv4 ACL's on recent Samba (particularly those at
> http://www.sambaxp.org/files/SambaXP2009-DATA/Nils_Goroll.pdf), and
> installed Samba 3.5.2 on test servers. And I've set up shares with the
> following settings.
> 
> [share]
> acl check permissions = False
> ea support = yes
> store dos attributes = yes
> map readonly = no
> map archive = no
> map system = no
> vfs objects = zfsacl
What platform is your Samba server running on? Is this
Solaris?

Volker

On Tue, Apr 20, 2010 at 07:45:00AM -0400, Nico Kadel-Garcia
wrote:
> Good morning, folks.
> 
> I'm involved in a project to enforce NFSv4 ACL's across a variety
of
> storage platforms, in particular NetApps sharing NFS. That works fiine
> with the NetApp NFS qtrees, but we'd like to share those with CIFS
> clients as well. This works, and restricts access the way we expect
> NFSv4 ACL's to work, but the Windows clients cannot view any of the
> security settings on the directories or files.
> 
> Cue the music, and enter Samba 3.5.2. I've reviewed various public
> notes on how to use NFSv4 ACL's on recent Samba (particularly those at
> http://www.sambaxp.org/files/SambaXP2009-DATA/Nils_Goroll.pdf), and
> installed Samba 3.5.2 on test servers. And I've set up shares with the
> following settings.
> 
> [share]
> acl check permissions = False
> ea support = yes
> store dos attributes = yes
> map readonly = no
> map archive = no
> map system = no
> vfs objects = zfsacl
> nfs4: mode = special
> nfs4: acedup = merge
> 
> The "map readonly" is rejected, and I'm not sure why.
What do you mean by "rejected" here ?
> The vfs objects seems to have no effect for NFSv4 access. NFSv4
> permissions do seem to be followed.
> 
> But Windows clients still can't see any of the security settings under
> the "Security" tab of properties.
What do you see here ?
> And really, really unfortunately, the NetApp ".snapshot"
directories
> are showing up by default. That's deadly: directory copy operations
> may attempt to include the .snapshot backup targets, and that would
> *really* get nutty.
Use the "veto files" parameter to hide them.

Jeremy.