`<div class="gmail_quote">On Sun, May 12, 2013 at 10:00 AM, Natxo Asenjo <span dir="ltr"><<a href="mailto:natxo.asenjo@gmail.com" target="_blank">natxo.asenjo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div class="im">On Sat, May 11, 2013 at 10:35 PM, Paul B. Henson <span dir="ltr"><<a href="mailto:henson@acm.org" target="_blank">henson@acm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Sat, May 11, 2013 at 09:12:43AM +0200, Natxo Asenjo wrote:Does the linux nfs client complain at all when you do the copy with<br></div></blockquote></div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
aclmode=restricted? The client would get a success for the open, but the<br>
following setattr op would fail, and I wasn't sure how the nfs client<br>
would deal with that. From the strace output it looks like the<br>
underlying nfs setattr failure isn't passed back up to the userland<br>
code, it looks like the open just succeeds as normal. Cool.<br>
<br></blockquote></div><div><br>no, it does when moving a file though :</div></div></blockquote><div><br>mm, when using scp it bypasses the acl as well ..., grrr.<br><br>So far I have seen that copying the files *after* the the files have been copied from the remote client, then the acl is preserverd.<br>
<br>I guess this will have to do until nfs4.1 is in illumos (is there a roadmap on that)?<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote">
<div>-- <br></div></div><span class="HOEnZb"><font color="#888888">groet,<br>natxo<br>
</font></span></blockquote></div><br>
`