Case-Sensitive Filename Handling in Samba Shares: Windows Compatibility and Operational Consistency Analysis


10 views

When configuring Samba shares between Unix/Linux systems and Windows clients, filename case sensitivity creates unique operational challenges. The default Samba configuration (case sensitive = no) presents a significant risk when case-sensitive filenames exist on the Unix side.

With case sensitive = yes in smb.conf:

[global]
    case sensitive = yes
    preserve case = yes
    short preserve case = yes

Windows clients will observe:

  • Both "RODDY" and "roddy" directories appear as distinct entities
  • File operations maintain case consistency
  • Attempts to access case-variant names return proper errors (STATUS_OBJECT_NAME_NOT_FOUND)

Consider this test scenario on the Unix server:

mkdir /share/{RODDY,roddy}
touch /share/RODDY/file1.txt
touch /share/roddy/FILE1.TXT

Windows Explorer will show both directories and their contents exactly as named. Attempting to delete "RODDY" will only affect that specific case variant.

1. Application Compatibility:
Some Windows applications may handle case-sensitive paths unpredictably. Visual Studio, for example, might normalize paths during project operations.

2. Performance Impact:
Case-sensitive matching requires additional filesystem lookups, measurable in high-traffic environments.

For mixed environments, consider:

[shared]
    path = /data/share
    case sensitive = auto
    hide special files = no
    veto files = /~*/.DS_Store/

The auto setting provides balanced behavior:
- Preserves case for display
- Performs case-sensitive operations
- Maintains Windows-compatible error handling

If experiencing issues:

# Check effective Samba configuration
testparm -v | grep -i case

# Monitor real-time operations
sudo smbstatus -L -v

When configuring Samba shares between UNIX/Linux systems and Windows clients, the case sensitivity setting (default: case sensitive = no) creates a particularly dangerous edge case. While Windows traditionally treats filenames as case-insensitive (NTFS is case-preserving but not case-sensitive), UNIX systems can have multiple distinct files with names differing only in case.

# Example of problematic directory structure on UNIX:
drwxr-xr-x 2 user group 4096 Jan 1 10:00 RODDY/
drwxr-xr-x 2 user group 4096 Jan 1 10:01 roddy/

With case sensitive = no in smb.conf:

  • Windows shows both "RODDY" and "roddy" folders
  • File operations become non-deterministic - accessing either name might affect either directory
  • No visual distinction or warning about the collision

When setting case sensitive = yes:

[share]
   path = /srv/samba/share
   case sensitive = yes
   # Other required parameters...

The behavior becomes:

  • Windows clients see both directories exactly as they exist on UNIX
  • File operations are now deterministic - case is preserved and respected
  • BUT: Windows applications may still exhibit case-insensitive behavior when accessing files

For development environments where case sensitivity matters (e.g., git repositories, code projects):

# Recommended smb.conf settings for developer shares:
[code]
   path = /var/repos
   case sensitive = yes
   hide special files = no
   create mask = 0644
   directory mask = 0755
   veto files = /.git/

Watch out for:

  1. Windows applications that force lowercase (e.g., some IDEs)
  2. Mixed-case references in build scripts
  3. Git operations (core.ignorecase should match your Samba setting)

If case sensitivity causes issues:

# Use veto files to prevent creation of mixed-case duplicates
veto files = /*[A-Z]*/*[A-Z]*/
delete veto files = yes

Or implement pre-creation checks:

# In smb.conf:
[share]
   path = /srv/samba/share
   case sensitive = auto
   mangled names = no
   mangling char = _

For critical systems, consider:

  • Enforcing lowercase-only naming conventions
  • Implementing filesystem hooks to prevent case collisions
  • Using Samba's hide dot files and hide special files to reduce visibility of system files

Create a test script to verify behavior:

#!/bin/bash
# Create test directories
mkdir -p /srv/samba/test/{RODDY,roddy}

# Test file operations from Windows:
echo "Case test RODDY" > /srv/samba/test/RODDY/file.txt
echo "Case test roddy" > /srv/samba/test/roddy/file.txt

# Verify SMB access:
smbclient //localhost/test -U% -c "ls RODDY; ls roddy"