On Wed, 2012-12-05 at 17:23 +0100, Florian Manschwetus wrote:
> Am 05.12.2012 16:41, schrieb Myklebust, Trond:
> > On Wed, 2012-12-05 at 10:48 +0100, Florian Manschwetus wrote:
> >> I setup a little network using a central storage server based on
> >> nexenta-Communityedition clients use homes and several shares via nfs4.
> >> As we have some shares used for webdevelopment purposes it is desired to
> >> have acls inherited for specific groups access and user access
> >
> > Inherited acls are inherently incompatible with basic POSIX
> > open(O_CREAT). The latter takes a mode bit argument that will clobber
> > your inherited acl.
> >
> >> (webserver user). I also have trouble with sticky-bit inheritance, which
> >> is needed as the linux gui tools unaware of nfs-acls. Are there plans to
> >> improve support for nfs acls?
> >>
> >> Maybe someone here have successfully a solaris nfs server running with
> >> linux clients using extended acls, with inheritance working as expected?
> >>
> >> It is really annoying having users not allowed to view/edit files/dirs
> >> they copied just the moment.
> >
> > This is not the right list for requesting gui tool changes. The right
> > address would be the GNOME, KDE and XFCE project mail lists.
> >
> Sounds reasonable, but at least a cp -r /share/orig /share/copy should
> produce a copy with expected acls (as defined on /share).
>
> My normal outcoming is that the user coping the directory is unallowed
> to access it, by @owner-deny ace. Which is really ugly. Unfortunately I
> can't find a mode making the server to enforce correct inheritance
> (disallowing the users to alter acls, mode, etc via nfs, maybe with
> nfs-acls tools but this isn't really needed).
Doesn't the '--preserve=xattr' argument help?
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
