<div>Bind 9.7.1 - 9.14.5 - 9.14.7 and 9.15.3 is dropping this into sys.log, but still runs fine:

<br></div><div><br></div><div>named[459]: unable to set effective uid to 0: Operation not permitted
<br></div><div>named[459]: generating session key for dynamic DNS
<br></div><div>named[459]: unable to set effective uid to 0: Operation not permitted<br></div><div>
named[459]: sizing zone task pool based on 2 zones<br></div><div><br></div><div>Some ancient info in the mail list archives, shows some people running into this message also at 9.7.1:<br></div><div><a href="https://lists.isc.org/mailman/htdig/bind-users/2010-September/081230.html">https://lists.isc.org/mailman/htdig/bind-users/2010-September/081230.html</a><br></div><div><a href="https://lists.isc.org/mailman/htdig/bind-users/2010-September/081233.html">https://lists.isc.org/mailman/htdig/bind-users/2010-September/081233.html</a><br></div><div><a href="https://lists.isc.org/mailman/htdig/bind-users/2014-July/093460.html">https://lists.isc.org/mailman/htdig/bind-users/2014-July/093460.html</a><br></div><div><br></div><div>At v9.14.1 <a rel="nofollow" title="http://bind-users-forum.2342410.n4.nabble.com/BIND-9-14-0-unable-to-set-effective-uid-to-0-Operation-not-permitted-td6844.html" target="_blank" href="http://bind-users-forum.2342410.n4.nabble.com/BIND-9-14-0-unable-to-set-effective-uid-to-0-Operation-not-permitted-td6844.html"> [Found this link] </a>describing named wanting to revert the files back to UID 0, root for some reason even though it is in chroot at this time.<br></div><div><br></div><div>The ISC git page also discusses the issue:
<a href="https://gitlab.isc.org/isc-projects/bind9/issues/1042" rel="noreferrer nofollow noopener" target="_blank">https://gitlab.isc.org/isc-projects/bind9/issues/104</a><br></div><div><br></div><div>Seems to happen when making these files on startup while in chroot and wanting to change them back to UID 0<br></div><div> /srv/named/var/run/named/session.key<br></div><div>/srv/named/var/run/named.pid<br></div><div><br></div><div>Some people tried to satisfy the condition by adding root to group root and changing the file ownership to root.<br></div><div><br></div><div>If you disable caps --disable-linux-caps at compile time ( but at the cost of security, and no one knows what that cost is?!?)<br></div><div>the messages go away.<br></div><div><br></div><div>Running on an LFS 9.0 build with libcap 2.27  no PAM, Virtualbox<br></div><div><a href="http://linuxfromscratch.org/blfs/view/svn/server/bind.html">http://linuxfromscratch.org/blfs/view/svn/server/bind.html</a><br></div><div><br></div><div>Anyone with some info, please let me know.
<br></div><div>Time to relabel the messages to be more clear about it being a WARNING or an ERROR?<br></div><div>Or someone clearly indicating that these messages can be ignored would be helpful.<br></div><div><br></div><div>Thanks so much.<br></div>