Custom Query (292 matches)

In Samba 3.3 the location definition of the codepage files (upcase.dat, lowcase.dat and valid.dat) results in a mess:

We define the codepages directory to be a directory named "codepages" as a subdirectory of the executable directory.

The result is that depending upon which component is looking for the files they are searched in the following places:

ndpsmb.dll via EVFSCTL.EXE: x:\ecs\bin\codepages\*
ndpsmb.dll via NetDrive:    %NDFSDIR%\codepages\*
Any Samba executable:       exedir\codepages\*

Considering there are likely the commandline utilities installed another set is searched at x:\ecs\system\samba\codepages\*

Proposed solution: Let's move the codepages directory to %ETC%\samba\codepages similar to the way we have done it for other Samba data files.

I think that when the configuration wizard creates the initial configuration, it should use the "SYSTEM" charset for all of dos/unix/display charset settings, not "IBM-850" (which is a strange choice in any non-European country). As far as I understand "SYSTEM" means the current system codepage. This will cause Samba to use the system codepage both locally (which is obviously correct) and when talking to DOS clients (which is also correct as clients that have a different 8-bit local encoding won't be able to show the correct file names anyway).

I have two OS/2 machines. Setting all charsets to SYSTEM on both of them is the only way when they see each other's national (cyrillic in this case) file names correctly through the ndpsmp plugin (which uses the same smb.conf as the server AFAIR). Also, from my iMac (which is UTF-8 everywhere) I see correct file names on both machines w/o touching any configuration files.

The problem is found in 3.0.25rc1, rc2 and rc3. It was not there in 3.0.25pre2 and earlier.

When a whole drive (i.e. K:/ or K:) is shared in smb.conf AND a loglevel of 3 or 4 is defined in smb.conf, connecting to the share will fail with a NT_STATUS_BAD_NETWORK_NAME.

I have provided some logs as attachments to this ticket. Browsing the logs (search for "K:/" in the log.samba.192.168.1.3 files), you will see that it is quite obvious, why this fails, as there are garbage characters after the share name:

If the smb.conf section looks like:

[k]

path = k:/

the logfile entry at loglevel 3 or 4 will be:

[2007/04/13 17:20:15, 0] smbd/service.c:make_connection_snum(1014)

'K:/d 548 ' does not exist or permission denied when connecting to [k]

Note the the garbage after K:/ !

A workaround for this problem is either not to use loglevel 3 or 4 or use a different notation in smb.conf:

[k]

path = k:/./

Both measures make the problem go away.

Additional notes:

• The problem does not occur with with loglevel 1, 5, 6 and 10, others not tested.

• WinXP is sometimes able to connect successfully at the second attempt, smbclient.exe however can never connect.