# named: the working directory is not writable



## mgp (Feb 2, 2009)

Hi,
I've been seeing this complaint for some time and I'm still not sure what exactly the problem is
I see this in /var/log/messages when I start named:

```
named[1284]: starting BIND 9.4.3-P1 -t /var/named -u bind
named[1284]: command channel listening on 127.0.0.1#953
named[1284]: the working directory is not writable
named[1284]: running
```
and when I do

```
# chown -R bind /var/named
```
and start named again I get this:

```
# /etc/rc.d/named start
. changed
        user expected 0 found 53 modified
etc changed
        user expected 0 found 53 modified
etc/namedb changed
        user expected 0 found 53 modified
etc/namedb/master changed
        user expected 0 found 53 modified
var changed
        user expected 0 found 53 modified
Starting named.
```
and the same in /var/log/messages:

```
named[1541]: starting BIND 9.4.3-P1 -t /var/named -u bind
named[1541]: command channel listening on 127.0.0.1#953
named[1541]: the working directory is not writable
named[1541]: running
```
and the owner of /var/named is set back to root

what is this caused by and how do I fix it ? 
thank you

regards
mgp


----------



## Mel_Flynn (Feb 12, 2009)

It is what's called "programmer inflected useless warnings".

The directory option is used for 2 things:
- The working directory for named
- The base directory for relative path references

For some reason named finds it worth mentioning that it can't write anything in this directory since a few releases. Conventional setups have not written in the named base dir for decades, but all of a sudden it's important to spit into logfiles.

If you really want this message to go away, you will need to change the directory option, like:

```
options {
    // Paths
    directory           "/etc/namedb/letskeepthisdirwriteable";
}
```
As a result all your relative path references need to be rewritten, like:

```
zone "." {
    type slave;
    file "[B][color="Red"]../[/color][/B]slave/root.slave";
    masters {
        192.5.5.241;    // F.ROOT-SERVERS.NET.
    };
    notify no;
};
```

I found it better to just ignore this warning.


----------



## vivek (Feb 13, 2009)

I run named in jail (not freebsd jail) and keeping a writable directory won't make any difference. Infact I need writable directory so that query log written to /var/named/chroot/var/log directory and later it can be used by rrdtool (bindgraph.pl) to create nice graphs. Also, I keep security logs so I need directory writable.


----------



## Mel_Flynn (Feb 18, 2009)

vivek said:
			
		

> I run named in jail (not freebsd jail) and keeping a writable directory won't make any difference. Infact I need writable directory so that query log written to /var/named/chroot/var/log directory and later it can be used by rrdtool (bindgraph.pl) to create nice graphs. Also, I keep security logs so I need directory writable.



It's not about /var/named/chroot/var/log, it's about whatever directory you have set in named.conf as the 'directory' option. If unset, compiled in default is used, which is /etc/namedb. You don't want this directory writeable as any hole in Bind will allow the attacker to instantly rewrite named.conf and do nasty things.


----------



## Ofloo (May 17, 2009)

This can be solved by changing

# $FreeBSD: src/etc/mtree/BIND.chroot.dist,v 1.6.20.1 2009/04/15 03:14:26 kensmith$
#
# Please see the file src/etc/mtree/README before making changes to this file.
#

/set type=dir uname=bind gname=wheel mode=0755 << this line used to contain uname=root instead


----------



## SirDice (May 17, 2009)

Which will make the directory writable and susceptible to the attack Mel_Flynn mentioned. Hence it is not recommended.


----------



## InspectorGadget (Nov 7, 2009)

Sorry to reboot an old thread but what's wrong with this picture?  Were you guys just born?  I've been using FreeBSD for decades and in recent years over several versions of BIND I've never had this error.  What was the deal on those machines?  Were they configured writable by default, or has something in the configuration or reporting in BIND changed?

And isn't the sandbox set up so that you can be insulated against that kind of risk if you enable directory write?


----------



## brucec@ (Dec 11, 2009)

InspectorGadget said:
			
		

> And isn't the sandbox set up so that you can be insulated against that kind of risk if you enable directory write?



The named.conf gets copied from /etc/named to /var/named/etc/namedb so bind can access it, so if you make /var/named writable then an attacker, despite not being able to escape from the sandbox, could still rewrite named.conf.


----------



## Savagedlight (Mar 24, 2010)

I have this same issue, but I can't ignore it.

/var/log/messages

```
named[96348]: transfer of 'domain/IN' from a.b.c.d#53: failed while receiving responses: permission denied
named[96348]: dumping master file: /etc/namedb/tmp-Ubg6isB4J2: open: permission denied
```

This is because it tries to create a new temporary file but has no permission to do so.

How to solve this? :|


----------



## Ofloo (Mar 24, 2010)

The way I solved it is in the post however this isn't the proper solution, .. 



> This can be solved by changing
> 
> # $FreeBSD: src/etc/mtree/BIND.chroot.dist,v 1.6.20.1 2009/04/15 03:14:26 kensmith$
> #
> ...



Few weeks ago I got a reply from FreeBSD team which solved the problem.


```
Synopsis: named(8): the working directory is not writable

State-Changed-From-To: open->closed
State-Changed-By: dougb
State-Changed-When: Sat Mar 13 21:42:38 UTC 2010
State-Changed-Why: 

This problem has already been fixed in more recent versions of FreeBSD.
You should update, in rough order of precedence, to 8-stable, 8.0-RELEASE,
7-stable, or 7.3-RELEASE (when it comes out). Bonus points for being
part of the solution by testing a 7.3 release candidate. 

hope this helps,

Doug

http://www.freebsd.org/cgi/query-pr.cgi?pr=134616
```

I hope this helps ?

EDIT: I'm not sure if this is the same problem though.


----------



## SirDice (Mar 24, 2010)

Savagedlight said:
			
		

> I have this same issue, but I can't ignore it.


Different issue. Yours is a configuration error.



> /var/log/messages
> 
> ```
> named[96348]: transfer of 'domain/IN' from a.b.c.d#53: failed while receiving responses: permission denied
> ...



You need to store that zone data in the /etc/named/slave/ directory.


----------



## chrcol (Mar 25, 2010)

I also am seeing it in the logs.

regarding the freebsd reply the machine I see it on is 8-STABLE


----------



## jaywheeler (Jun 14, 2010)

I am also getting these error messages on the start up console and in the logs.

Currently using 8.0-Release, but also saw it 7.2-Release.


----------



## SirDice (Jun 14, 2010)

Ignore it.


----------



## bmth (Feb 23, 2020)

Unfortunately, you cannot just ignore it anymore. At least with BIND 9.14 (installed from packages). I tried it on a machine running FreeBSD 12.1 and encountered this problem:

```
named[24831]: the working directory is not writable
named[24831]: loading configuration: permission denied
named[24831]: exiting (due to fatal error)
```
First, I decided bind doesn't have a permission to access one of its configuration files, but after few hours of reading and trying the solutions read (then reading and trying again and again), it all ended up with the working directory recursively owned by bind and bind started manually (rc script for bind silently resets directory permissions, that I was unaware of, and that made finding the reason for bind fail a bit more complicated). After that bind started successfully. Then I rewoke writing permissions for working directory for bind. Bind failed to start. So this is not just a warning anymore.

Since I don't want for a static dns server to be able to write anything on the machine, I reverted to BIND 9.11. This guy works fine even with unwritable working directory.


----------



## dgs (Apr 22, 2022)

This error typically happens when upgrading from BIND 9.11 to BIND 9.14 or later. The issue is that BIND used owner root and group wheel for the /usr/local/etc/namedb directory. When BIND 9.14 was released they changed the requirement to owner bind group bind for /usr/local/etc/namedb. The fix is as follows:

chown bind:bind /usr/local/etc/namedb

There is no error message in the /var/log/messages file outside of "the working directory is not writable". Hope this helps.


----------

