testparm.exe chokes on its own output (was:SSCC trashes smb.conf upon exit)

[Herwig Bauernfeind]

With Samba 3.3.x, when changing smb.conf using SSCC.EXE, smb.conf is trashed when quiting SSCC.EXE.

This is a spin-off from Ticket #145 (as this deals with several unrelated issues).

[Herwig Bauernfeind]

Ok, found the reason for this bug: The problem is not really in SSCC.EXE (it just cannot cope with the situation), but in testparm.exe, which chokes on its own output from testparm -v

Reproduction scenario:

1. Run

   testparm -v 1>%ETC%\samba\smb.conf
   

That is basically what sscc.exe does when switching into expert mode. The result is an smb.conf with all valid Samba 3.3 options.

2. Now run

   testparm 1>emptysmb.conf 2>errormsgfromtestparm
   

You see that we simply get an error message from testparm.exe and no more output. The error msg is

Load smb config files from D:\MPTN\ETC/samba/smb.conf
creating default valid table
creating default valid table
creating default valid table
params.c:pm_process() - Failed.  Error returned from params.c:parse().
Error loading services.

Note: testparm.exe from a recent Samba 3.0.37 considers the very same output from 3.3-testparm.exe as a valid smb.conf. It only complains about several unknown parameters (which is to be expected).

[Herwig Bauernfeind]

More research on this bug reveals that testparm.exe chokes on the following parameters:

idmap uid =
idmap gid =
copy =

Removing these from smb.conf makes the problem go away.

A workaround similar to the one added for the winbind separator problem would make SSCC.EXE usable with Samba 3.3.x until this problem is fixed in testparm.exe.

[Silvan Scherrer]

works as designed, those parameters are not allowed to be blank.

[David McKenna]

I upgraded to the new SAMBA 3.3.15 -eCS 1.1.0-565 (from 1.0.6 using SSCC 1.01) and ran into this exact problem again. Is there some way to make SSCC check smb.conf to make sure all required lines are present and warn if not (with suggestions for missing lines)? It's not nice using SSCC and then discovering your server doesn't work any more and smb.conf has been blanked....

[Herwig Bauernfeind]

Samba 1.0.6 WPI came with SSCC.exe 1.0.0 which trashed smb.conf while used together with Samba 3.3.x when switching into expert mode and back.

SSCC.EXE 1.0.1 (available as a standalone package from ​here has a workaround implemented as described above. 1.0.1 should not trash smb.conf anymore (and it does not, when tested with the above scenario, as I just re-tested).

So could you please confirm that SSCC.EXE 1.0.1 trashed your smb.conf? If so there must be a loophole in the workaround... Sorry for the inconveniance.

[David McKenna]

According to 'Help' -> 'About' it is version 1.01, dated 6/13/2011. To reproduce, all I need to do is open SSCC, switch to 'Expert mode', then click the 'Close' button. SMB.conf then only has 3 header lines. I will upload my original SMB.CONF.

[David McKenna]

working smb.conf for SAMBA 3.3.15

[Herwig Bauernfeind]

Ok, I can reproduce. There is a loophole. Will fix it ASAP.

[Herwig Bauernfeind]

Please try new SSCC from ​here.

[David McKenna]

Wow... thanks for the speedy update! This one works well, and the new smb.conf seems to have all parameters listed after using 'Expert Mode'. Very nice!