Learn Samba - Samba in Docker/Kubernetes

#Introduction

For 18 episodes, Samba ran on "bare" servers. Episode 19 touches the reality of modern infrastructure: containers and Kubernetes. Running Samba in a container isn't just style — it gives reproducibility (config in the image, not on the machine) and orchestration. But Samba is a stateful service: data and config must live outside the container. Understanding where that "state" lives is the heart of this episode.

#Samba in Docker

#Available Images

Two most popular community images:

• linuxserver/samba: an Alpine-based image with environment variables (USER, PASS, SHARE) — good for simple NAS setups.
• dperson/samba: a flexible image with command-line arguments (-u user -p pass -s "share;/path;yes;no;no") — easy to script.

Both provide ready-to-use smbd + nmbd. An example with dperson/samba:

docker run -d --name samba \
  -p 445:445 -p 139:139 \
  -v /srv/data:/data \
  -v samba-config:/config \
  dperson/samba -u arman -p S3curePass! \
    -s "data;/data;yes;no;no"

Key points:

• -p 445:445 -p 139:139: expose the SMB ports from the container to the host.
• -v /srv/data:/data: file-share data goes on a host volume — data survives even if the container is removed.
• -v samba-config:/config: Samba configuration and state (e.g. passdb.tdb) in a named volume.
• -u arman -p ... -s "...": dperson arguments for user, password, and share definition.

#Samba in Kubernetes

#StatefulSet: The Right Choice

A stateful service with a stable identity — fixed name, hostname, and storage — is the textbook use case for a StatefulSet (not a Deployment, which is stateless with changeable identity). A manifest skeleton:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: samba
spec:
  serviceName: samba
  replicas: 1
  selector:
    matchLabels: { app: samba }
  template:
    metadata:
      labels: { app: samba }
    spec:
      containers:
        - name: samba
          image: dperson/samba:latest
          ports:
            - containerPort: 445
              name: smb
          volumeMounts:
            - name: data
              mountPath: /data
            - name: config
              mountPath: /config
          args:
            - -u
            - arman
            - -p
            - $(SAMBA_PASS)
          env:
            - name: SAMBA_PASS
              valueFrom:
                secretKeyRef: { name: samba-secret, key: password }
  volumeClaimTemplates:
    - metadata: { name: data }
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests: { storage: 100Gi }
    - metadata: { name: config }
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests: { storage: 1Gi }

Important points in this manifest:

• volumeClaimTemplates creates a separate PVC per pod — storage is guaranteed persistent and created automatically when the pod is born.
• The password comes from a Secret (valueFrom), not hardcoded in the manifest — a mandatory security habit.
• Two volumes: data (share contents) and config (Samba state) — both persistent.

#Service: Exposing Samba

Samba must be reachable by clients via a stable IP — use a Service with the SMB ports:

apiVersion: v1
kind: Service
metadata:
  name: samba
spec:
  selector: { app: samba }
  ports:
    - name: smb
      port: 445
      targetPort: 445
      protocol: TCP
  type: LoadBalancer

LoadBalancer provides a single external IP (e.g. from MetalLB/cloud LB) that forwards to the Samba pod. Clients only need to know \\<IP>\share — just like using a physical server.

#Correct Patterns and Their Traps

#The Stateless-Container, Stateful-Storage Pattern

A summary of the correct pattern:

• Container = reproducible Samba process (image + args).
• State = share data (/data) and config/user DB (/config) on persistent volumes.
• Dynamic configuration via env/secrets, not manual editing inside the container.
• A stable Service (LoadBalancer/NodePort) exposes ports 445/139.

#Common Traps

• State in the container: users and passwords vanish on pod restart — always use volumes (see the Callout above).
• replicas > 1 for fake HA: multi-pod standalone Samba = lock conflicts; use CTDB + RWX if you truly need scale.
• Wrong Kubernetes probes: Samba has no HTTP endpoint; a readinessProbe can use tcpSocket on 445, not httpGet.
• Image :latest: the latest tag isn't reproducible; pin the image version in production.
• NetBIOS in the cluster: nmbd and NetBIOS broadcast don't work well over Kubernetes overlay networks — modern clients via DNS/445 only.

#Kubernetes-Specific Pitfalls

Beyond the patterns above, note:

• hostNetwork vs Service: using hostNetwork: true avoids IP translation (SNAT) that can break old SMB connections, but binds the pod to one node. For simple production, a Service with correct MTU is usually enough.
• MTU mismatch: an overlay network with a different MTU than storage/clients can make SMB connections slow — match the jumbo MTU across the whole path.
• Volume backup: a StatefulSet doesn't back up data; make sure the PVC is backed up (e.g. via snapshot or Velero — the learn-velero series).

#Closing

Key takeaways:

• The linuxserver/samba and dperson/samba images run Samba easily; state must be on volumes, not the container layer.
• Kubernetes uses a StatefulSet (stable identity + storage) and a LoadBalancer Service to expose SMB ports.
• Passwords from Secrets; never hardcode them in the manifest.
• replicas > 1 without CTDB is fake HA — lock conflicts, not resilience.
• Pin the image version and plan PVC backups from the start.

In episode 20 next, we'll cover performance & monitoring — tuning aio read size, use sendfile, NIC bonding, monitoring with smbstatus and Prometheus node_exporter, plus log analysis. A fast and monitored Samba is a production-worthy Samba!