Bind: unable to lock file /etc/nam.conf


We’ve got a problem with a sles11 sp2 oes11 sp2 system.
On starting named there come an message: Starting name server BIND unable to lock file /etc/nam.conf
On the machine bind 9.9.4-P2 is running. novell-named is not installed here.
I found this with another problem. The IPS on our firewall block dns packages with dns-amplification attack DoS/DDoS
Any ideas?

Thanks ins advance for your answers.

Best regards.

Dirk Emmermacher

The /etc/nam.conf file is owned by the namcd process, not named. sp the
processes around ‘named’ should not really matter.

Is this system’s hostname ‘bind’?

Are you sure this is OES 11 SP2 and SLES 11 SP2? That combination is not
allowed, so it is usually OES 11 SP2 with SLES 11 SP1, or OES 11 SP2 with
SLES 11 SP3.

What do you mean about your firewall blocking ‘dns packages with
dns-amplification attack DoS/DDoS’? I’m not sure how that applies, but
perhaps you’re providing information around DNS just in case.

Is there anything about this server that does not seem to work, besides
the odd error message? Is the ‘namcd’ process running? Do commands like
‘id admin’ (or some other user in your eDirectory tree) work properly?

Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

Hello ab.

Thanks for you answer.
This is installed on the server:
mx:~ # cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)

mx:/etc # cat novell-release
Novell Open Enterprise Server 11 (x86_64)
VERSION = 11.1

The hostname is mx (groupwise)

Here is the status of named:
mx:/etc # rcnamed status
Checking for nameserver BIND
version: 9.9.4-P2 id:3f00a920
CPUs found: 1
worker threads: 1
UDP listeners per interface: 1
number of zones: 102
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running

The namcd is up and running.
the “id admin” works. For admin I’ve got a uid, a gid and a groupname.

ndsrepair -T gaves the right timesync and ndsrepair -R works without any errors.

The namcd needs on startup one or two minutes.

The local firewall is off. The messages are from our central firewall.
The logmessages started at night. So I’m sure, that this changes were not the result of updates or modifications on the machine.

Best regards.