/dev/null behaving strangely

[Arthur Chance]

My main fileserver is showing very strange symptoms.

It's running 10.3-RELEASE-p18, GENERIC kernel, amd64. I can't get a
uname from it into this mail as this is from another box and neither ssh
nor scp work to the file server.

It started about 20 minutes ago when I got mail from cron

----
From: operator at bede.home.qeng-ho.org (Cron Daemon)
To: operator at bede.home.qeng-ho.org
Subject: Cron <operator at arthur> /usr/libexec/save-entropy

Date: Wed, 07 Jun 2017 18:22:00 +0100

/usr/libexec/save-entropy: cannot create /dev/null: Permission denied
----

This is now happening every 10 minutes as the cron job runs. However,
running save-entropy from the command line (on the console, or over ssh
before I rebooted) works without complaint. Since I rebooted I cannot
ssh or scp to the file server, getting the errors

arthur at arthur[7]> ssh root at fileserver
Couldn't open /dev/null: Permission denied

arthur at arthur[4]> scp fileserver:/tmp/t /tmp/t
Couldn't open /dev/null: Permission denied

ls -l /dev/null gives a possibly interesting result: on two other boxes
I get

root at arthur:3# ls -l /dev/null
crw-rw-rw-  1 root  wheel  0x1f  7 Jun 18:05 /dev/null

but on the file server the device number is 0xd rather than 0x1f (owner,
group and permissions are identical). I'm not sure if this is
significant. Rebooting the file server has had no effect on the problem,
other than cutting off ssh access.

The system disk is a relatively new SSD and smartctl shows no problems
with it. devfs mounting on /dev is the default set up, and now jails are
running to confuse things.

Any ideas?

-- 
An amusing coincidence: log2(58) = 5.858 (to 0.0003% accuracy).