<div dir="ltr">PS. Don't forget that if you change or disable AppArmor you will have to reboot the host so the kernel gets reloaded.</div><br><div class="gmail_quote"><div dir="ltr">Em qua, 24 de out de 2018 às 09:40, Erlon Cruz <<a href="mailto:sombrafam@gmail.com">sombrafam@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think that there's a change that AppArmor is blocking the access. Have you checked the dmesg messages related with apparmor?</div><br><div class="gmail_quote"><div dir="ltr">Em sex, 19 de out de 2018 às 09:38, Neil Jerram <<a href="mailto:neil@tigera.io" target="_blank">neil@tigera.io</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Wracking my brains over this one, would appreciate any pointers...<div dir="auto"><br></div><div dir="auto">Setup: Small test deployment with just 3 compute nodes, Queens on Ubuntu Bionic. The first compute node is an NFS server for /var/lib/nova/instances, and the other compute nodes mount that as NFS clients.</div><div dir="auto"><br></div><div dir="auto">Problem: Sometimes, when launching an instance which is scheduled to one of the client nodes, nova-compute (in imagebackend.py) gets Permission Denied (errno 13) when calling utime to touch the timestamp on the instance file.</div><div dir="auto"><br></div><div dir="auto">Through various bits of debugging and hackery, I've established that:</div><div dir="auto"><br></div><div dir="auto">- it looks like the problem never occurs when this is the call that bootstraps the privsep setup; but it does occur quite frequently on later calls</div><div dir="auto"><br></div><div dir="auto">- when the problem occurs, retrying doesn't help (5 times, with 0.5s in between)</div><div dir="auto"><br></div><div dir="auto">- the instance file does exist, and is owned by root with read/write permission for root</div><div dir="auto"><br></div><div dir="auto">- the privsep helper is running as root</div><div dir="auto"><br></div><div dir="auto">- the privsep helper receives and executes the request - so it's not a problem with communication between nova-compute and the helper</div><div dir="auto"><br></div><div dir="auto">- root is uid 0 on both NFS server and client</div><div dir="auto"><br></div><div dir="auto">- NFS setup does not have the root_squash option</div><div dir="auto"><br></div><div dir="auto">- there is some AppArmor setup, on both client and server, and I haven't yet worked out whether that might be relevant.</div><div dir="auto"><br></div><div dir="auto">Any ideas?</div><div dir="auto"><br></div><div dir="auto">Many thanks,</div><div dir="auto">      Neil</div><div dir="auto"><br></div></div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>
</blockquote></div>