dumping master file: tmp-xxx: open: permission denied

[David Forrest]

On Tue, 14 Jan 2014, LuKreme wrote:

>
> On 13 Jan 2014, at 20:36 , Mark Andrews <marka at isc.org> wrote:
>
>>
>> In message <8919443E-8F62-48CD-8DA4-9C9632FC5D69 at kreme.com>, LuKreme writes:
>>> OK, I am getting this error "dumping master file: tmp-xxx: open:
>>> permission denied", occasionally, on both my slave DNS servers and I
>>> can't seem to fix it.
>>>
>>> The dns slave files are being written into /var/named/etc/namedb/slave
>>> which is owned by bind
>>>
>>> 8 drwxr-xr-x  2 bind  wheel  1024 Jan 13 19:46 /var/named/etc/namedb/slave
>>>
>>> DNS changes are getting propagated to both servers from the master, so I
>>> don't know where the permission denied is coming from. Where is this
>>> tmp file being (attempted to be) written?
>>
>> It's trying to write the the working directory which I doubt is
>> /var/named/etc/namedb/slave.  I suspect you have a bad "file"
>> directive.
>
> Hmm. OK, there is a /var/named/etc/namedb/working/ which is also owned by bind.
>
> Where might this bad file directive be? The only ‘file’ in named.conf are in the form “slave/example.com” and the pid-file setting.
>
>> And why are the slave servers "dumping master file" in the first place?
>>
>> So the slave can start up and serve the zone content when the master
>> server is down.
>
> Oh? Coolness :)

I've been tripped up on this before as there is a default directory and 
the default can be overridden by a "directory" option statement.  Using a 
chroot adds the current definition into the chrooted directory.  It can 
get quite confusing and I have found that just using full paths on all 
zone files just cuts out any question. Usually the slave server will get a 
new copy master fairly quickly if you don't save it but it is cleaner if 
it has a fairly recent copy locally.

Dave

-- 
David Forrest      e-mail: drf at maplepark dot com
St. Louis, Missouri