⚠

Auto-generated content — pending SME review

This content was auto-generated from Fusion SMB documentation and is pending SME review. Please verify accuracy before using in partner-facing contexts.

Log Collection & Analysis

Effective log collection is critical for diagnosing Fusion SMB issues and for providing complete data when escalating to Tuxera Support. This page covers log configuration, audit logging, and how to interpret log output.

Server Logging

Fusion SMB generates logs that allow you to monitor server activity and troubleshoot issues. Each log line consists of metadata and content. The metadata may include:

• Timestamp — ISO 8601 format
• Thread ID — the thread that generated the message
• Log level — severity of the event
• Module name — the topic/subsystem that generated the message

Log Destinations

Fusion SMB can write logs to three destinations:

Destination	Use Case	Configuration Value
Console (stdout/stderr)	Initial setup and testing	log_destination = console
System log (syslog)	Integration with centralized log management	log_destination = syslog
File	Dedicated Fusion SMB log file	log_destination = file

Log Levels

Log levels control the verbosity of output. Higher numbers produce more detailed logs:

Level	Description	When to Use
1	Errors only	Production (minimal overhead)
2	Warnings + errors	Production (recommended)
3	Informational	General monitoring
4	Debug	Active troubleshooting
5–6	Trace / Verbose	Deep diagnostics (high volume)

You can also set per-module log levels to focus on specific subsystems. For example, log_level = 4 idmap:40 sets the general level to 4 but increases idmap logging to level 40 for detailed identity mapping diagnostics.

Recommended Troubleshooting Configuration

For active troubleshooting, use the following configuration to capture detailed logs to a file:

[global]
. . .
log_destination = file
log_level = 4 idmap:40
log_params = path=/var/log/tsmb.log,long,timestamp,time_usec=false,tid,trace,sensitive_data=strip
. . .
[/global]

This produces log lines like:

2024-09-17 02:09:10 <124844> [INFO] process: tsmb-server version 3024.3.22.1.evaluation starting...
2024-09-17 02:09:10 <124844> [INFO] process: Waiting for METRICS to initialize ...
2024-09-17 02:09:10 <124844> [INFO] process: METRICS initialized.
2024-09-17 02:09:10 <124859> [12] idmap: loading userDB backends by list 'text'
2024-09-17 02:09:10 <124859> [12] idmap: initializing 'static' userDB backend

Log parameter options:

• path — log file location
• long — include detailed metadata
• timestamp — add timestamps to each line
• time_usec=false — use second-level precision (set to true for microsecond precision)
• tid — include thread ID
• trace — include trace information
• sensitive_data=strip — redact sensitive data from logs (recommended)

tip

Always use sensitive_data=strip when collecting logs that will be shared with third parties or attached to support cases. This prevents accidental exposure of credentials or sensitive user data.

Runtime Log Level Changes

You can change the log level without restarting the server:

# Increase log level for active troubleshooting
sudo tsmb-cfg global set log_level 6

# Revert to normal level after troubleshooting
sudo tsmb-cfg global set log_level 3

Audit Logging

Audit logging provides a detailed record of file operations performed on shares. This is separate from the server log and is designed for compliance, forensics, and detailed troubleshooting.

Audit Levels

Audit levels are incremental — each higher level includes all events from lower levels:

Level	Operations Logged
1	Create, Delete, Rename, Modify permissions, Authentication (session setup/logoff)
2	Level 1 + Write, Update (flush)
3	Level 2 + Read permissions, Lookup, Readdir
4	Level 3 + Read operations
5	Level 4 + Stat, IOCTL COPYCHUNK, Share root open

Enabling Audit Logging

Audit logging requires two configuration steps:

Step 1: Enable audit logging globally and configure output parameters:

[global]
. . .
audit_enable = true
audit_params = path=/var/log/tsmb-audit,days=1,uid=true
. . .
[/global]

Step 2: Set the audit level per share:

[share]
netname = MyShare
path = /export/share
audit_level = 3
[/share]

Or via CLI:

sudo tsmb-cfg share add -n MyShare -p /export/share -A 3

When to Use Audit Logging

• Compliance requirements — regulatory mandates for file access tracking
• Security investigations — tracing who accessed or modified specific files
• Permission troubleshooting — understanding why access is being denied by reviewing the actual SMB operations

Performance Impact

Higher audit levels generate significantly more log volume, especially Level 4+ which logs every read operation. Use Level 1–2 for production and only increase during active investigations.

Server Statistics

Fusion SMB exposes always-on diagnostic metrics via tsmb-status. These metrics provide real-time visibility into server activity without needing to configure logging.

Collecting Statistics

# Full statistics in JSON format (recommended for support cases)
tsmb-status stats --format json > /tmp/fusion-stats-$(date +%Y%m%d-%H%M%S).json

# Tabular format for quick human review
tsmb-status stats --format tabular

# Filter by category
tsmb-status stats --category session --format json
tsmb-status stats --category connection --format json

Key Fields to Check

Session fields:

• Username — who is connected
• Signing required / Encryption required — security settings in effect
• Guest — whether the session was authenticated as guest
• Rx plain/encrypted/signed pkts — packet type distribution (useful for diagnosing signing/encryption issues)

Connection fields:

• Dialect — negotiated SMB protocol version
• Signing Alg / Cipher Alg — active security algorithms
• RX/TX bytes — traffic counters
• Operations — per-operation counts and durations (useful for identifying slow operations)

Correlating Sessions and Connections

Sessions and connections are linked by Conn ID. To find all connections for a specific user:

jq --arg user "username" '
  . as $root
  | $root.session[]
  | select(.Username == $user)
  | . + {
      connections: [
        .Connections[] as $cid
        | $root.connection[]
        | select(."Conn ID" == $cid)
      ]
    }
' /tmp/fusion-stats.json

Log Collection Checklist for Support Cases

When collecting diagnostic data for a support case, gather:

• Server log — filtered to the timeframe of the issue, at log level 4 or higher
• Server statistics — tsmb-status stats --format json output captured near the time of the issue
• Configuration file — tsmb.conf (redact passwords if needed)
• Audit log — if the issue involves file access permissions or compliance concerns
• Fusion SMB version — tsmb-server -v output
• OS information — Linux distribution and kernel version
• Packet capture (if requested or if the issue involves application-specific behavior) — tcpdump -i any -s 0 -w capture.pcap port 445, filtered to the issue timeframe

Reference: For complete logging parameter documentation, see Logging and Server Statistics on docs.tuxera.com.

✍Knowledge Check

1. What log_params setting should always be used when sharing logs with third parties?

2. What audit level should be used for production environments?

3. How do you change the log level at runtime without restarting?