Blixt Documentation v2.9

In this walkthrough you run BlixtFS on a small Linux server in your office or cloud network, and serve a bucket to desktops as an SMB share.

Plan

  • Server: a Linux VM with Docker, close to the users or in the same region as the bucket, with a dedicated disk for /data.
  • Bucket: one bucket for the share, for example gs://acme-shared.
  • Access: one shared SMB account for the team.

Turn on object versioning for the bucket before you start. It protects the team against accidental deletes and overwrites. See Backup and recovery.

1. Configure BlixtFS

Create /srv/blixt/config.yaml:

general:
  default_cloud: gcp

cloud:
  gcp:
    enabled: true
    project: acme-prod
    credentials: /credentials
    buckets:
      - bucket: gs://acme-shared

smb:
  default_user: team

filesystem:
  default_uid: 1000
  default_gid: 1000

2. Start it

docker run -d --name blixt --restart unless-stopped --privileged \
  -p 445:445 \
  -v /srv/blixt:/data \
  -v /srv/blixt-secrets/gcp.json:/credentials:ro \
  -e AUTH_TOKEN="$(openssl rand -hex 32)" \
  blixtfs/standard:2.9.0 --config /data/config.yaml \
  --smb_default_password "$TEAM_PASSWORD"

Allow TCP port 445 from the office network in the server’s firewall, and from nowhere else.

3. Connect the desktops

Windows: in File Explorer, choose This PC › Map network drive, pick a letter, and enter \\blixt-server\bfs. Sign in as team.

MacOS: in Finder, choose Go › Connect to Server and enter smb://blixt-server/bfs. Sign in as team.

The share contains gcp/acme-shared/. Create a desktop shortcut to that folder for convenience.

4. Move the existing files in

Copy the old file server’s contents into the share with a tool that preserves timestamps, such as robocopy on Windows or rsync on Linux and MacOS. Everything copied lands in the bucket as ordinary objects.

For large migrations it can be faster to upload directly to the bucket with your provider’s tools (gcloud storage cp, aws s3 sync). BlixtFS picks the objects up through change notifications.

What to watch

  • Local disk: size /data so the team’s working set fits in the cache.
  • Upload backlog: large copies are staged locally and uploaded in the background. Leave the server running until they have drained.