Windows → Linux File Server

Summary

Windows file servers get replaced with AlmaLinux 9 running Samba — while the Windows Active Directory domain itself stays exactly where it is. Users see no difference: the same file shares, the same permissions, the same login they already know. What changes is what’s underneath it.

The real-world reasons this matters:

  • Lower licensing cost — every Windows Server eliminated from the file-serving role is real, ongoing licensing cost that stops recurring.

  • Full permission fidelity — this isn’t a simplified, "good enough" file server. Every Windows NTFS permission — deny rules, inheritance, granular access control — is fully supported and manageable through the exact same Windows Security tab your staff already knows.

  • Simpler, more resilient failover — a warm standby server in the private cloud stays ready with no ongoing synchronization headache, for reasons explained below.

This approach has been possible in theory for years. What made it practical in practice was a specific, deliberate architecture choice — covered next.

The Three Permission Layers

Every file share’s real-world access control comes down to three layers stacking on top of each other — true on Windows, true here:

Layer What it controls

Share permissions

The door to the share itself — who can connect at all. Same concept, same behavior, on both platforms.

Filesystem permissions

Basic read/write/execute, stored on the filesystem itself.

Advanced ACLs

The granular rules — explicit deny, inheritance control, "this folder only" scoping — that a real office environment actually needs day to day.

The first two layers map cleanly between Windows and Linux. The third layer — advanced ACLs — is where past attempts at this migration usually broke down, and where the real engineering work went.

Solving the Advanced-ACL Gap

Linux’s native permission model (POSIX) is coarser than Windows' NTFS — it has no built-in concept of explicit deny rules or per-entry inheritance control. The fix: Samba stores the actual, complete Windows permission set as an extended attribute directly on each file, served back to Windows clients exactly as they’d expect — not a simplified translation, the real thing, verbatim.

This requires a filesystem with enough room to store that data faithfully on complex permission sets — AlmaLinux 9’s default filesystem (XFS) handles this correctly out of the box.

Why This Used to Be Hard, and What Actually Changed

Linux-based Windows file serving has a real, deserved reputation for being painful — but the specific pain point was never the file serving itself. It was reliably mapping Windows user identities to Linux permissions in a way that didn’t drift, corrupt, or disagree between servers over time.

The fix is a genuinely elegant piece of modern tooling: identity mapping is now handled algorithmically — the same Windows user always produces the exact same Linux identity, wherever and whenever it’s computed, with no local database to maintain, back up, or worry about corrupting. Practically, that means:

  • Rebuilding a server after a failure produces identical permissions — automatically.

  • Adding a second server produces identical permissions — automatically.

  • Migrating a customer to new hardware requires no identity reconciliation at all.

That single change is what turned this from "theoretically possible, always a headache" into "genuinely production-ready."

Resilience: Warm Failover Without the Usual Headache

Because identity mapping is computed the same way every time, a standby server in the private cloud can be kept continuously in sync with a simple, well-understood file copy — and stay ready to take over immediately, with no separate step to reconcile user permissions afterward. Activating it is a DNS/mapped-drive change, not a reconstruction project.

Get in touch to talk through what this looks like for your environment.