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

[LuKreme]

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?

And why are the slave servers "dumping master file" in the first place?

--
Carlin's Third Commandment: Thou shall keep thy religion to thyself.

[Mark Andrews]

In message <8919443E-8F62-48CD...@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.

> 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.

> --
> Carlin's Third Commandment: Thou shall keep thy religion to thyself.
>

> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

[LuKreme]

On 13 Jan 2014, at 20:36 , Mark Andrews <ma...@isc.org> wrote:

>
> In message <8919443E-8F62-48CD...@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 WILL STOP TALKING ABOUT THE TWELVE INCH PIANIST Bart chalkboard Ep.
3F07

[David Forrest]

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

[LuKreme]

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

[David Forrest]

On Tue, 14 Jan 2014, LuKreme wrote:

>
> On 14 Jan 2014, at 09:02 , David Forrest <d...@maplepark.com> wrote:
>
>> On Tue, 14 Jan 2014, LuKreme wrote:
>>
>>>
>>> On 13 Jan 2014, at 20:36 , Mark Andrews <ma...@isc.org> wrote:
>>>
>>>>
>>>> In message <8919443E-8F62-48CD...@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

[Doug Barton]

On 01/14/2014 08:14 AM, LuKreme wrote:
> 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?

No. All path names in your configuration file should be relative to the
chroot directory. So /etc/namedb/slave/kreme.com.

You seem to be using FreeBSD. The default named.conf has the
configuration you should start with if you're using the default rc.d
script to start named. Start with that, follow the examples, and only
change things in the default if you're certain you know what the
implications of those changes will be.

Doug