So, my client blurted stuff like this:
cp: preserving permissions for
`/tmp/afra/leda/incl/LEDA/pixmaps/button32/index.xpm': Operation not
supported
cp: preserving permissions for
`/tmp/afra/leda/incl/LEDA/pixmaps/button32/ruler.xpm': Operation not
supported
cp: preserving permissions for
`/tmp/afra/leda/incl/LEDA/pixmaps/button32/watch.xpm': Operation not
supported
cp: preserving permissions for
`/tmp/afra/leda/incl/LEDA/pixmaps/button32/maze.xpm': Operation not
supported
cp: preserving permissions for
`/tmp/afra/leda/incl/LEDA/pixmaps/button32/make_file.xpm': Operation
not supported
cp: preserving permissions for
`/tmp/afra/leda/incl/LEDA/pixmaps/button32/tex_file.xpm': Operation
not supported
cp: preserving permissions for
`/tmp/afra/leda/incl/LEDA/pixmaps/button32/home.xpm': Operation not
supported
cp: preserving permissions for
`/tmp/afra/leda/incl/LEDA/pixmaps/button32/c_file0.xpm': Operation not
supported
but the script returned nothing on the server
On 8/30/06, Sam Falkner <Sam.Falkner at sun.com> wrote:
> On Aug 30, 2006, at 4:36 PM, Joe Little wrote:
>
> > On 8/30/06, Sam Falkner <Sam.Falkner at sun.com> wrote:
> >> On Aug 20, 2006, at 6:56 PM, Joe Little wrote:
> >>
> >> > We've noticed that on at least RHEL4 systems mounting from a
> >> Solaris
> >> > 10 U2 and Solaris 11 server using NFS v3, an ls in a given
> >> directory
> >> > shows many files with a '+' at the end of their permissions. This
> >> > isn't documented anywhere for Linux nor Solaris, but we only see t
> >> > his from our ZFS-backed Solaris systems.
> >> >
> >> > -rw-r--r--+ 1 jlittle games 918 May 17 2004 group
> >>
> >> This means that the file has an ACL on it. Or at least that's what
> >> "ls" is trying to say.
> >>
> >> > That's an example..
> >> >
> >> > Second, when we use "cp -p" to copy any file that has the + symbol,
> >> > we get:
> >> >
> >> > #cp -p filename /tmp
> >> > cp: preserving permissions for `/tmp/filename': Operation not
> >> > supported
> >> >
> >> > Any people can clue me in here? Is there a mode that one needs to
> >> > enable to use V3? Otherwise, using V2 solves things for us, but
> >> then
> >> > we lose visibility of snapshot trees in ZFS.
> >>
> >> ACLs aren't built in to the v3 protocol. Instead, we have a side
> >> protocol, which Linux also implements.
> >>
> >> What should be happening is that your client asks our v3 server for
> >> an ACL, our server asks ZFS for a POSIX-draft ACL, which it doesn't
> >> support, so our server fakes up an ACL based upon the mode, and
> >> returns it to you.
> >>
> >> But obviously that's not what's happening. Could you send us a snoop
> >> trace?
> >>
> >> If you're ambitious, could you run this DTrace script on the server,
> >> and send us the output? Save the script, make it executable, and run
> >> it; then, on the client, try the "cp -p". Then kill the script, and
> >> send us what (if any) output it generated. Thanks!
> >>
> >> - Sam
> >>
> >>
> >
> > I didn't see this reply until today. We figured out that we could just
> > mount with "noacl" on the linux end. I'll look into the dtrace and
> > such hopefully soon, but we've already gone production on the affected
> > systems and so I'll put together a different client to test this.
>
> I forget that attachments get deleted by the mailing list software.
> So, here it is inline. (Joe, I think you should already have it;
> this is just for anyone else curious.)
>
> #! /usr/sbin/dtrace -Fs
>
> acl3_getacl:entry
> {
> self->spec = speculation();
> self->resp = args[1];
> /* tail-call elimination, I curse you! */
> self->caller = caller;
> }
>
> :::entry
> /self->spec/
> {
> speculate(self->spec);
> }
>
> :::return
> /self->spec/
> {
> speculate(self->spec);
> trace(arg1);
> }
>
> :::return
> /caller == self->caller && self->resp && self->resp->status/
> {
> commit(self->spec);
> }
>
> :::return
> /caller == self->caller && self->resp && self->resp->status == 0/
> {
> discard(self->spec);
> }
>
> :::return
> /self->caller && caller == self->caller/
> {
> self->spec = 0;
> self->resp = 0;
> self->caller = 0;
> }
>
> - Sam
>
