<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 4, 2015 at 5:56 PM, Matthew Green <span dir="ltr"><<a href="mailto:mephi@mephi.co.uk" target="_blank">mephi@mephi.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">The host is expected to be the NFS server to start with, but using bind mounts (I think this is what you're suggesting) gives me concerns about portability and backups.</div><div class="gmail_extra"><br></div></blockquote><div><br></div><div><br></div><div>(1) Not EVERY use case is suitable for unpriv containers. So don't be surprised if yours isn't one of them.</div><div><br></div><div>(2) IIRC it's NOT recommended to have an nfs client mounting nfs share from localhost (i.e. loopback nfs mount), At least in old kernels: <a href="https://lwn.net/Articles/595652/">https://lwn.net/Articles/595652/</a> . Not sure about current (e.g. 4+) kernels though.</div><div><br></div><div>(3) What kind of "portability" are you talking about here? Moving between virt systems (e.g. KVM -> lxc, or whatever)? If its THAT, then you'd always have to perform some level of adjustment anyway, with or without additional bind mounts.</div><div><br></div><div>If you mean "what happens when the nfs server is on another server", then the host can import the share on the SAME path as you're currently using, and bind-mount will continue to work (as long as the path and owner/permission is the same)</div><div><br></div><div>(4) you create a backup strategy that fits your needs.</div><div><br></div><div>-- </div><div>Fajar</div></div></div></div>