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

[David Forrest]

On Tue, 14 Jan 2014, LuKreme wrote:

>
> On 14 Jan 2014, at 09:02 , David Forrest <drf at maplepark.com> wrote:
>
>> 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.
>
> so I should change
>
> zone "kreme.com" { type slave; masters { 75.148.37.67; }; file "slave/kreme.com";  };
>
> to
>
> zone "kreme.com" { type slave; masters { 75.148.37.67; }; file “/var/named/etc/namedb/slave/kreme.com";  };
>
> and that will eliminate the errors?

This works for me.  At least I then know where it is going.

>
> or are you saying that in options { … I should set
>
> directory “/var/named/etc/namedb/“
  No. this just sets up another redirection to work out.  YMMV though


> If I change the ownership of /var/named/etc/namedb to bind, it gets changed back to root when bind starts.

I'm on CentOS65 and it seemed to not notice I was running as named -u named and 
this tripped me up too in my init so I added a statement just before it 
executes (around line 170 in /etc/rc.d/init.d/named) the start daemon to 
change the ownerships to named;  like this:

169  chown -hR named:named /var/named                       ## DRF
170
171 daemon --pidfile "$ROOTDIR/$PIDFILE" /usr/sbin/"$named" -u named ${OPTIONS};

But I am sure there is a proper way to do this.  Expediency usually bites. 
Maybe some can tell us

-- 
David Forrest      e-mail: drf at maplepark dot com
Maple Park Development     http://www.maplepark.com
St. Louis, Missouri