I understand the top shelf issue. My server is in the attic. 6.x currently goes EoL in September 2019 and these dates only seem to go backwards so you have plenty of time yet. You should be able to go to v8 directly. With it's mainstream kernel, you may be able to automatically pull the old drivers from ElRepo repo so the rebooting issue goes away

Nick Howitt wrote:

I do compile a forcedeth driver here and the issue in that thread you linked to has gone away as the devs have dropped the plan to revert to a stock kernel in 7.x and will instead, do it in 8 from the outset. This is the safer option. However there is still a risk. These days RedHat only seem to be keeping ABI compatibility in the kernels within their point releases, so many of the drivers need to be recompiled when a kernel goes up along with EL7 going up a point release. This means, as an example, the forcedeth driver is fine for the 7.4 kernels (kernel-3.10.0-693.x.y.v7.x86_64) but needs to be recompiled (with slightly modified sources) for the 7.5 kernel (3.10.0-862.x.y.v7). The risk for you is not spotting the kernel update and the machine rebooting in your absence which will put the new kernel into effect and cut your internet. If it happens, it can be salvaged if you can talk your user through booting to an older kernel (just hitting the down arrow at a critical time during the boot process).

Apologies about the chkconfig command. It worked with 7.x. In 6.x if you turn it off and on again, it also enables runlevel 2 :S

Can you check that all your interfaces are valid in /etc/clearos/network.conf

Thanks Nick. Yes, network.conf looks sensible. I'll be tinkering with the smb configuration tomorrow - when everyone's out.

The only worry with the reboot to old kernel option is that someone has to climb up to the top of the shelves and connect a monitor/keyboard/mouse. The grizzling I'd have to put up with isn't worth it!

I do compile a forcedeth driver here and the issue in that thread you linked to has gone away as the devs have dropped the plan to revert to a stock kernel in 7.x and will instead, do it in 8 from the outset. This is the safer option. However there is still a risk. These days RedHat only seem to be keeping ABI compatibility in the kernels within their point releases, so many of the drivers need to be recompiled when a kernel goes up along with EL7 going up a point release. This means, as an example, the forcedeth driver is fine for the 7.4 kernels (kernel-3.10.0-693.x.y.v7.x86_64) but needs to be recompiled (with slightly modified sources) for the 7.5 kernel (3.10.0-862.x.y.v7). The risk for you is not spotting the kernel update and the machine rebooting in your absence which will put the new kernel into effect and cut your internet. If it happens, it can be salvaged if you can talk your user through booting to an older kernel (just hitting the down arrow at a critical time during the boot process).

Apologies about the chkconfig command. It worked with 7.x. In 6.x if you turn it off and on again, it also enables runlevel 2 :S

Can you check that all your interfaces are valid in /etc/clearos/network.conf

eth0 External Static 192.168.100.2
eth1 LAN Static 192.168.1.1

eth0 connects to my ADSL2+ modem with a static IP. The modem's DHCP is set to 192.168.100.100-199.
eth1 provides DHCP to my LAN

The nVidia is the NIC on the motherboard, it's the one not detected by ClearOS 7. This is an old Compaq presario CQ3000.

I appreciate that it's not that difficult, once the procedure is documented, to rebuild it after updates. The issue is that if I'm away then nobody else in the house knows anything about how to do it, so stability is very important. I don't want to have to drive 5 1/2 hours home from the snow next August to fix the internet LOL

Also it's the external NIC because it's only 10/100 and that's what passes for high speed broadband in Australia, meaning it can't be fixed from outside. The other NIC is gigabit, so it's better for the LAN.

Hence ClearOS 6.9 was the easier path.

Fair enough, though with auto update turned off (which you want anyway for reliability) and controlling when and what updates are applied that kmod driver should not be a problem - get the updated driver, update kernel, update driver - done...

You appear to only have one NIC according to your append - how is the ClearOS system configured? Does it have a static address or one assigned from another dhcp server? eg using the MAC address to always assign the same dynamic address...

Tony Ellis wrote:

By the way - there is a kmod driver for forcedeth available for ClearOS 7.4 if that is the reason for not installing 7.4...

I did find this thread on that but the thread also warned that updates could mean it needs to be reinstalled, so I didn't follow it up. This machine is the firewall/gateway for the whole house (1 university professor, 1 uni student and my own computer repair business) and the ear-bashing I got when it went down last week put me off doing anything too complex in case it causes more problems.

By the way - there is a kmod driver for forcedeth available for ClearOS 7.4 if that is the reason for not installing 7.4...

"service smb start" in /etc/rc.d/rc.local will try to start smb at boot - however, never had this problem going all the way back to the ClarkConnect days...

That means it should start for run-levels 3, 4 and 5 - which is normal and which the ClearOS 6.X systems here are set for...

[root@server ~]# chkconfig --list | grep smb
smb 0: off 1: off 2: off 3: on 4: on 5: on 6: off
[root@server ~]#

Try
chkconfig --list | grep smb

Thanks for the reply

Havcing already done a "service smb start" from the command line (yesterday) I now get :

[root@server ~]# service smb status
smbd (pid 8509) is running...
[root@server ~]# chkconfig smb
[root@server ~]# lspci -knn | grep Eth -A 3
00:07.0 Bridge [0680]: NVIDIA Corporation MCP61 Ethernet [10de:03ef] (rev a2)
Subsystem: Hewlett-Packard Company Device [103c:2a99]
Kernel driver in use: forcedeth
Kernel modules: forcedeth
--
01:0a.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller [10ec:8169] (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8169/8110 Family PCI Gigabit Ethernet NIC [10ec:8169]
Kernel driver in use: r8169
Kernel modules: r8169
[root@server ~]#

As you can see, chkconfig smb returns nothing.

I'm sure we've tried digging into this before but is smb set to auto-start? What is the output to "chkconfig smb"? If it is set to auto-start, is there anything in the boot log? I once had an issue with not nmb starting but never smb.

Also, with respect to your NIC, what is the output of:

lspci -knn | grep Eth -A 3

[edit]
To start manually, try editing /etc/rc/d/rc.local
[/edit]

I don't know if it helps, but I;ve just done a clean install of ClearOS 6.9 (because 7 doesn't recognise one of my NICs) and had the same problem I;ve had with every ClearOS install l've done for the last few years - the smb service doesn't start when the machine is booted. I've fixed it each time by editing one of the init files to do a "service smb start" (can't remember which one - it's actually a job for tomorrow for me) and then it works fine.

After the update of June the 29th I have problems to access the flex shares. I'm using Windows 10 and I have only 1 user on the Windows computer no guest account. The other Windows 10 computer has the same problem. Also from my Android tablet I'm not able to access the shares. I can't find any error messages on the Clearos server. I'm using Clearos 7.2.0 Kernel 3.10.0-327.10.1.v7.x86_64
What could be the problem?

I get the reply access denied.