named mystery -- error: dumping master file: master/tmp-wTjhUzoix6

Alex Goncharov alex-goncharov at
Mon Sep 1 12:50:50 UTC 2008

For quite a while I've been trying to understand how to work around
this little annoyance: named periodically writes

  dumping master file: master/tmp-dnbiuWrKNQ: open: permission denied

to `/var/log/message'.

Sure, I thought -- out of the box the `master' directory doesn't give
write permission to user bind:

$ pwd; ls -ld master
drwxr-xr-x  2 root  wheel  512 Aug 17 13:47 master/

If, in a default setup, I change the owner of `master' to `bind', a
`named' restart will revert the ownership to `root', due to the
settings in `/etc/mtree/BIND.chroot.dist'.

So, a couple of months ago I changed the latter:

$ diff /etc/mtree/BIND.chroot.dist~ /etc/mtree/BIND.chroot.dist
<             master
>             master  uname=bind

After this change, every time I restart `named', the ownership of the
`master' directory is changed to `bind' -- and this is what I want:
user `bind', I would think, should be allowed to write to this

Every time after the restart everything is working well: no complains
about the `master/tmp-XXX' files (which are zone dumps -- I did look
at the code.)

But also every time some time after the restart (perhaps a week or two
down the road), something (and I can't figure out what), changes the
owner of `master' to `root' -- and the zone dump gets impossible.

Not that this leads to any problem in my DNS operations but I am
totally flabbergasted about this behavior: looked at the code, did all
kind of Internet searches and experiments, and still don't have an
idea on:

  Who changes the owner of the `master' directory from `bind' to

(The only thing I can think of is the dynamic DNS updates by DHCP

At this point, I pulled back my change to
`/etc/mtree/BIND.chroot.dist' -- there is no use in it if somebody
overrides my preference later, silently.

Does anybody know what's going on?  Who is that "silent changer"?
What settings should I change to get things work right?


-- Alex -- alex-goncharov at --

More information about the freebsd-current mailing list