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

LuKreme kremels at kreme.com
Tue Jan 14 16:14:48 UTC 2014


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?

or are you saying that in options { … I should set 

directory “/var/named/etc/namedb/“

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

-- 
"Those people who think they know everything are a great annoyance to
those of us who do." - Isaac Asimov



More information about the bind-users mailing list