And how to avoid hiring a full-time Linux team
Hi, I’m Chris Boot, CTO here at Tiger Computing. I’ve been working with Linux and Tiger for over 10 years; across enterprises, research environments, cloud infrastructure, and, increasingly, with MSPs.
Most MSPs I meet are doing a brilliant job supporting their clients’ Windows estates, M365 environments, and broader IT needs. But when Linux shows up in a client environment (whether it’s a production server, web app, or something running in AWS) that’s when things can get a little… unpredictable.
In this post, I’ll walk through five of the most common mistakes I’ve seen MSPs make when supporting Linux systems. My aim isn’t to call anyone out; it’s to help you avoid the headaches and keep your clients happy (and your team sane).
1. Treating Linux Like It’s Just Windows with a Terminal
It’s easy to assume that because both systems run on servers and have networking and users, they work more or less the same. They don’t.
Linux isn’t just Windows with a command line. The entire operating model is different; file permissions, package management, services, logging, security, patching – it all behaves in ways that aren’t immediately obvious unless you’ve lived and breathed it.
Real-world example:
We once worked with an MSP whose engineer had tried to troubleshoot a stuck process using commands they’d picked up from Google. They accidentally killed a service that controlled all SSH access and locked themselves out. Cue the emergency break-fix Linux support and some very red faces.
Tip: If your team isn’t confident with Linux, don’t assume. Double check, or better yet, get a second opinion.
2. Leaving Linux Servers Off Your Monitoring and Patching Routines
Windows systems tend to be automatically enrolled in RMM platforms. Linux systems? Not always. They get left out, either because the tooling isn’t configured for them or because no one’s quite sure how to onboard them.
This creates a blind spot. Unpatched Linux boxes are often visible to the internet, running outdated software, and not even being checked.
Real-world example:
One MSP we supported was unaware their client’s publicly exposed Linux server hadn’t been patched in over 18 months. It was running a vulnerable version of OpenSSH. Fortunately, we caught it before someone else did.
Tip: Make sure Linux systems are visible in your stack; even if you’re not managing them day-to-day. And if you are, treat patching and monitoring as critical, not optional.
3. Assuming the Client Knows What the Linux Box Does
We’ve seen a lot of orphaned infrastructure: a mysterious Linux server humming away in the corner that no one dares touch because “it’s probably important.” Spoiler: it usually is.
Whether it’s running a critical file sync, an old ERP system, or a data collector for a legacy app, Linux often gets brought in for a very specific task – and then forgotten.
Real-world example:
An MSP called us in after their client’s “unused” Linux server was decommissioned during an office move. Turns out it was managing secure FTP transfers for a key partner. Downtime wasn’t pretty.
Tip: Always ask what the system does, then verify it. A quick audit (and some log reading) can save a lot of pain.
4. Underestimating the Linux Skills Gap
Linux skills aren’t just a checkbox; they’re deep, and often highly specialised. Asking a junior engineer to “take a look” at a Linux issue when they haven’t touched Linux in five years is unfair to them and risky for the client.
Real-world example:
We often work with clients whose engineers regularly reboot Linux servers to apply minor configuration changes which causes avoidable extended downtime. We can often apply such changes with only seconds of disruption, or none at all.
Tip: If Linux isn’t part of your core expertise, don’t rely on guesswork or old knowledge. It’s okay to ask for backup.
5. Not Having a Go-To Linux Partner
Many MSPs either try to cover Linux in-house (even when it’s not a good fit), or they say no to the work altogether. Neither option is great for long-term client relationships.
The MSPs we see thriving are the ones who say:
“We don’t do Linux ourselves, but we’ve got a specialist partner we trust.”
That way, they can still say yes to their clients; without putting pressure on their internal team or risking mistakes.
Real-world example:
We’ve partnered with MSPs across the UK to deliver everything from routine Linux support to high-availability cluster design and troubleshooting. In every case, the MSP stays in control of the client relationship – we’re just the Linux people in the background.
Tip: You don’t need to build a Linux team overnight. You just need the right partner when you need them.
Avoiding Linux Support Pitfalls as an MSP
Linux is increasingly present in modern client environments. Whether it’s powering web applications, databases, file servers, or something more exotic. It’s not going away.
You don’t need to be a Linux expert to support clients who use it. But you do need to know someone who can.
If you’re running into Linux-shaped challenges in your client base, let’s have a chat. We’re not here to take over. We’re here to help you deliver the kind of service your clients expect; without any drama.
Request a call back and let’s talk about how we can support you.
