This has been going on  a while and this machine might stay up for weeks or just 2 minutes.  I am getting these logs in my syslog  any help would be appreciated.

 

May 15 12:27:56 Tower kernel: nf_conntrack: table full, dropping packet
May 15 12:30:50 Tower kernel: nf_conntrack: table full, dropping packet
May 15 12:30:55 Tower kernel: nf_conntrack: table full, dropping packet
May 15 12:32:03 Tower ntpd[1394]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
May 15 12:32:46 Tower in.telnetd[8258]: connect from 192.168.1.122 (192.168.1.122)
May 15 12:32:48 Tower login[8260]: ROOT LOGIN  on '/dev/pts/0' from '192.168.1.122'
May 15 12:33:59 Tower kernel: nf_conntrack: table full, dropping packet
May 15 12:33:59 Tower kernel: nf_conntrack: table full, dropping packet
May 15 12:37:02 Tower kernel: nf_conntrack: table full, dropping packet
May 15 12:37:03 Tower kernel: nf_conntrack: table full, dropping packet

syslog snippets are seldom useful without posting the full diagnostics

 

 

Not sure what files in particular so I attached the zip to this post.

Thank you

tower-diagnostics-20160515-1614.zip

 

http://www.pc-freak.net/blog/resolving-nf_conntrack-table-full-dropping-packet-flood-message-in-dmesg-linux-kernel-log/

I. What is the meaning of nf_conntrack: table full dropping packet error message

In short, this message is received because the nf_conntrack kernel maximum number assigned value gets reached.

The common reason for that is a heavy traffic passing by the server or very often a DoS or DDoS (Distributed Denial of Service) attack. Sometimes encountering the err is a result of a bad server planning (incorrect data about expected traffic load by a company/companeis) or simply a sys admin error…

Right, i understand but there is not dos attack and there is also not any file named nf_conntrack on the unraid machine that I can find.  Do you think a reinstall on my usb would fix this?  I just have no idea what this means.

A few comments -

 

* I noticed your 3rd DNS server is set to 4.4.4.4, shouldn't that be 8.8.4.4?

 

* I see ata_piix being used, so you have IDE emulation turned on for your SATA drives.  When you next boot, go into the BIOS settings and look for the SATA mode, and change it to a native SATA mode, preferably AHCI if available, anything but IDE emulation mode.  It should be slightly faster, and a little safer.

 

* The first nf_conntrack error occurs about 90 seconds after unRaid-Hole is initialized.  That's not a commonly used tool, so you may want to remove/disable it and see if that makes any difference.