*New 11.4 series Release:
2020-07-03: XigmaNAS - released!

*New 12.1 series Release:
2020-04-17: XigmaNAS - released

We really need "Your" help on XigmaNAS https://translations.launchpad.net/xigmanas translations. Please help today!

Producing and hosting XigmaNAS costs money. Please consider donating for our project so that we can continue to offer you the best.
We need your support! eg: PAYPAL

NAS4Free released (FreeBSD 11.0-RELEASE-P8)

Posts only related to Release Builds, all others will be removed!
Forum rules
Set-Up GuideFAQsForum Rules
Posts: 3
Joined: 14 Mar 2017 16:24
Status: Offline

SSHD not accepting connections sometimes


Post by thomasev »

I am using N4Free as backup (ZFS mirror and rsync). I am writing and using https://github.com/rsyncOSX/RsyncOSX, a Swift based macOS app (GUI for rsync). Setup for ssh is by private/public ssh keypair.

From time to time ssh daemon on N4Free does not accept ssh connection from my mac..

sshd[24782]: Did not receive identification string from port 52890

A successful connection is logged by

sshd[24791]: Accepted publickey for xxxxx from port 52894 ssh2: RSA

Does anyone know what causes problem?


experienced User
experienced User
Posts: 89
Joined: 24 Jun 2012 17:15
Status: Offline

Re: NAS4Free released (FreeBSD 11.0-RELEASE-P8)


Post by slaycock »

Sorry I can't be of help to you at this point because everything should be working without issue based on the info you supplied.
I upgraded all three servers I have to 32GB SSD as boot drives.

The SSD are persistent. Plugging in a USB drive (booting and rebooting etc) then removing and rebooting does not affect the ability to find and boot from the SSD.

Backup server #2 ( on an Intel based board) resolutely refuses to boot from a GPT partition and must be installed with a MBR formatted disk.

The Nas4Free installer cannot cope with reformatting a disk previously formatted as GPT so its necessary to wipe the initial and last sectors of the disk before installing the MBR version of NAS4Free.

All three machines were setup using 4029 and upgraded to 4040 before restoring the config. All three machines upgraded without issue.

After restoring the configs I found that 4066 was available.

The main backup server required three reboots before 4066 came up. There were two kernel panics relating to not finding PHY?

After a pause of 20 minutes the main server booted without problem. As the main server is very accessible this doesn't worry me too much.

Backup server #1 showed the same in-memory file system problem. A factory reset allowed upgrading to 4066 but this is annoying as I use 192.168.2 for my network not 192.168.1.

For Backup server #1 i restored the config and then attempted installing 4066 over 4066. It worked fine. No in-memory errors were reported.

Backup server #2 failed to reboot claiming a problem with /cf. On rebooting 4066 had been installed but the the config was default (

So my conclusion here is that there is possibly some issue with how the config files are managed.

Options for development would seem to be

1 Resolve the issue for doing an MBR install on a disk previously formatted using GPT (i.e include an option to dd the first two and lst two sectors of the target disk)

2 Allow the ip address of the target machine to be set when installing a new firmware. Then at least the target machine will be visible on the network if the config doesn't take.

The basic idea should be to give remotely managed machines a better chance of recovery if there are hiccups during a firmware installation or upgrade.

I just wish I enough knowledge and competence to attempt the above points but I don't. VBA word wizardry is about as far as I get.

Post Reply

Return to “Release Builds”