Samba:

Using "security = share" In smb.conf is not supported, therefore use "security = user".

SMB signing / DFS:

Normally, on Windows Server 2003 the options "Microsoft Network Server: Digitally sign communications (always)" and "Microsoft Network Server: Digitally sign communications (if client agrees)" are disabled in the "local security settings" (under "/Local policies/Security Options/") and "default domain controller security settings" (under "/Local policies/Security Options/").

However if one of them is enabled in your configuration or you are using Windows Server 2003 R2 / 2008 (which enables it by default), you'll need to change the settings (and reboot the server afterwards):

Local Security Settings / Local Policies / Security Options / Microsoft network server: "Digitally sign communications (always)" -> disabled
Local Security Settings / Local Policies / Security Options / Microsoft network server: "Digitally sign communications (if client agrees)" -> disabled

In case the settings cannot be changed, you may try to modify them directly in the Windows registry (run regedit.exe):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
enablesecuritysignature -> 0
requiresecuritysignature -> 0

If you set "usentlm" to "1" and signing is always enabled, users will receive an "Access denied" message, although their credentials are correct. Providing the credentials manually after the NTLM login has failed will also result in an "Access denied" message when signing is enabled.
When enabling signing in Windows 2003, you'll receive warnings that this breaks compatibility with clients, services and applications. This should be taken seriously since other components in your IT infrastructure may stop working correctly (e.g. portals / proxies that use NTLM / network scanners).
Therefore, when signing is enabled, make sure that "usentlm" is set to "0" in web.xml or change the configuration as described above.

When using DFS it is also recommended to disable signing on all servers involved in the DFS tree (including the server offering the DFS tree).
The DFS referrals are normally resolved with the Netbios names, but Netbios resolution is disabled in the webdisk to get better performance. So please make sure to add the Netbios names of the servers to the hosts file on the webdisk server (under Windows it is in \system32\drivers\etc\hosts, under Linux it is /etc/hosts).

If you're using "domain based" DFS instead of "stand-alone" in Windows 2003 Server R2, please make sure to add the domain name (e.g. win2k3test.local) and the IP of the domain controller as a new entry to the hosts file.

The netbios names can be found with "ipconfig /all" in the field "host name" (Windows) or in smb.conf (Linux).

Share names (only WebDisk versions older than 0.30):

Due to a limitation in the jCIFS library, share names may not be longer than 12 characters and they may not contain unicode characters. But ISO-based characters like German Umlaute are supported. In general this only means that those special share names are not visible in the list of shares. So you can anytime navigate to them by specifying a corresponding URL.

So you can get around this by:

• using the bookmark function: Simply place some bookmarks in the root of another share.
• using the Distributed File System (DFS): This way you have a share that contains links to other shares. To get this running with Samba, read this. For Windows and NetApp OnTAP refer to the corresponding documentation.

Note: This limitation only affects share names, not normal folders or files.

Note: Newer versions starting with 0.30 don't have this limitation.

Maximal path length:

Windows servers only support a maximum path length of 256 characters. That's the same with using Windows Explorer as a CIFS-client. If structures are deeper, you'll get error messages when trying to access them.

Samba servers only support a maximum path length of 1024 characters (even if the underlaying file system can handle more). If structures are deeper, you'll get error messages when trying to access them.

NetApp OnTAP servers don't seem to have a maximum path length. They may have one, but it is longer than those I've tested.