Linux Container Migration: Let's Consolidate the Chaos

Kinetic ERP
1

Hey all - there are at least 10 threads floating around right now all dealing with problems that trace back (directly or indirectly) to the Linux container migration. I figured it’d be helpful to pull everything into one place so Epicor has a single thread to respond to, and so the rest of us aren’t hunting across the forum trying to find solutions.

Related Threads

Background

Starting with 2025.2, Epicor began migrating cloud customers from Windows containers to Linux. Pilot environments started flipping over in late January/early February 2026, with Production migrations scheduled regionally through March and April.

Issue #1: Azure File Share Access Is Broken in Pilot

This is the big one. After Pilot environments moved to Linux, anything that reads from or writes to the Azure File Share started throwing “Permission denied” or “Could not find a part of the path” errors. Production (still on Windows) keeps working fine, which makes this even more fun to diagnose.

What’s getting hit: Bartender label generation, EDI documents, basically anything that touches the file share. It’s not just labels. If your code writes a file, it’s probably broken in Pilot.

There’s also the ConvertPath mess. Epicor added that method to some customers’ code to handle path differences, and now it’s deprecated in favor of FilePath. Code using the old UNC-style paths (//FTPsite/folder/...) just flat-out doesn’t work on Linux. And in at least one case, Epicor silently changed where ServerFolder.FileShare points, swapping it to FTP root instead of the Azure File Share, without telling anyone. No ticket, no notice, just suddenly your Bartender integration is broken and your files are somewhere unexpected.

Support’s best advice so far has largely been “disable the directive and retest,” which… isn’t a fix.

Issue #2: SSRS Reports

Post-2025.1, SSRS failures have been all over the place. We’re seeing data source not found errors, SQL connection timeouts, reports that can’t be copied or previewed, and a permissions error that showed up after the Linux migration that blocks copying report styles entirely.

There’s also a known (and annoying) path length bug. If your report style name is too long, it fails because Epicor appends its own stuff to the path and pushes it over ~100 characters. The fix is to use embarrassingly short names for your report styles. Fixed in 2025.2.10 apparently, but you still need the workaround on current versions.

One particularly bad bug was in the ICE DB ReportStore table where OOB reports got set to IsActive = False after an upgrade. That one required a datafix from support.

Issue #3: BPM and Function Editing Hanging or Crashing

After the migration weekend, some users couldn’t edit BPMs or Functions at all. Save would hang forever, or the client would just crash. Restarting the app server in Cloud Management Portal resolved it for most people, but it shouldn’t be happening in the first place.

There’s also a gap in Epicor’s own Linux compatibility report. It’s supposed to flag problematic code before migration, but it misses things. Some Function libraries with real ECF1002 errors don’t show up in the report at all. If you’re relying solely on that report to validate your customizations, you may have a false sense of security.

Configurator editing appears to be a separate but concurrent problem for some users, where saves just never resolve regardless of Linux.

Issue #4: MES Mode URL Broken in Pilot

The standard Data Collection URL (?mode=DC) isn’t routing to MES correctly on Linux Pilot environments. It just drops users into the full Kinetic UI instead. Epicor’s current workaround is to use Office MES or the Classic client. For anyone with a go-live coming up, that’s not exactly a satisfying answer.

The Process Problems (Separate from the Technical Ones)

Beyond the specific bugs, there are some patterns here worth calling out directly.

A lot of customers weren’t notified before their Pilot environments were flipped to Linux. The known issues list (the GitHub Gist that @Epic_Santiago has been maintaining) is genuinely helpful, but it lags behind what the community is discovering. And at least one customer had their environment configuration changed by Epicor without any notification at all.

The concern across all these threads is the same: if Pilot has this many open issues, why is Production migration still on schedule for March/April? We’ve been burned before by “it worked in Pilot.”

What’s Working as Workarounds Right Now

  • Restart your app server in CMP if BPM/Function editing is hanging
  • Shorten SSRS report style names significantly to stay under the path length limit
  • For file share access issues, open a ticket. There’s no self-service fix.
  • Check the known issues list here: Kinetic on Linux · GitHub
  • Check if your environment is on Linux via CMP, Tenant Instance, then select your environment
  • Use Office MES or Classic as a temporary workaround for the MES URL issue

Related PRBS from @Evan_Purdy

PRB # Description State Priority
PRB0311809 SSRS Report Designer broken on Linux host In Testing 3 - Moderate
PRB0312700 Pre-Issue - Unable to import Lookup tables into database on Linux Accepted 3 - Moderate
PRB0293934 GL Import file cannot be accessed by the server - Linux Server In Release Planning 3 - Moderate
PRB0294767 Linux - FIN W - Payroll Check Entry Electronic Banking Output file Validation compatibility for Linux In Release Planning 3 - Moderate
PRB0294244 COA Import file cannot be accessed by the server - Linux Server Accepted 3 - Moderate
PRB0294121 Linux - GL Financial Report Designer shows wrong font name under “Heading Font/Report Font” Accepted - Not Yet Planned 4 - Low
PRB0294664 FIN W - AR Invoice Entry - Intrastat export output file Validation Linux/Windows Accepted - Not Yet Planned 3 - Moderate
18 Likes
2

This has actually been fixed --or largely so-- with Hotfix G. We’re on hotfix H and are having our users test. :crossed_fingers:

2 Likes
3

Not sure if any of these aren’t in the thread:

image
image1797×905 50.8 KB

4 Likes
4

Not listed in here, but on the Github page is the Azure SSO/Entra ID login issues. I have changed the URI, however my coworkers still have issues logging in via SSO. For some reason, it gives me the error on the first login, but if I refresh and login again it will push me on in.

Anyone else still having SSO issues after updating Entra?

Edit: doing a bit more troubleshooting after posting this. Might be due to cache/cookies. Works without error in an InPrivate window and on a Terminal Server I have never logged into before. Going to clear my cache and try again…

Edit2: Clearing cache resolved my issues, going to have my coworkers do the same. If you still get the error after updating the URI in Entra, clear your browser cache!

2 Likes
5

For the Azure issue, while changing the path on all of your BPMs/Functions/Report Styles etc does work, I am waiting for clarification from support on what the plan is for our live environments.

I am really hoping for a more elegant solution for our live environments.

I am assuming I can’t make these changes in LIVE until I am on Linux in LIVE, so I would have to wait for my live environment to break until I can fix it.

3 Likes
6

Does anyone know the timeline for flex 2 to move to linux? I can see in the cloud management portal that the host is currently still windows. I checked status.epicor.com but I can’t find any announcements related to linux, and I haven’t seen any emails about it either.

3 Likes
7

Well, it wasn’t like us on cadence folks were informed either.

1 Like
8

Thank you for consolidating the Linux migration discussions into one thread.

I owe you all an update on the Linux Migration. I appreciate your patience as I continue to dig into the issues, the progress, and our areas of improvement. I don’t have all the answers yet, but I didn’t want it to go too long without a response from me.

FLEX 1 Environments Migrated in Error

A subset of FLEX 1 customers were migrated to Linux when they were not intended to be part of this phase. This should not have happened. Those affected received an email with directions on Friday, February 13, 2026. If you were affected and have not heard from us, please submit a support ticket.

This was a scoping error during execution, not intentional. We sincerely regret the disruption this has caused. I am personally working with the teams to document root cause.

For those of you in our Linux migration, all issues reported matter and have the most attention from our teams. I wanted to break down a few of them and they’re being addressed

First is the File Share / Azure File Share Access.

The shift from Windows UNC paths to Linux path structures (/epi/fs) exposed several areas where:

  • Customizations were tightly coupled to Windows-style paths
  • Validation logic in the application did not yet accept the new format
  • Some environment variables (including ServerFolder.FileShare) did not behave consistently

We are standardizing the mapping model and auditing environments to ensure consistent configuration. Path validation updates are being implemented in the application to eliminate these blockers.

This is the highest priority stabilization area.

Next is the SSRS Instability.

There were two separate issues that occurred:

  1. A configuration defect caused approximately 50% of report calls to fail. A validated fix is being rolled out - you all may have it by now.
  2. In some environments, SSRS requests were routed to a mix of Windows and Linux servers. That created intermittent success/failure patterns, which understandably appeared chaotic.

This was not a Linux platform limitation, but a configuration variance from the validated deployment architecture. This didn’t happen to all customers, but some very specific edge-cases that were causing issues. That variance has been identified and corrected.

We are adding post-migration validation checks specifically to prevent mixed-server routing from occurring again.

Lastly, the BPM / Function Editing & MES URL.

The BPM/Function editing hangs that are resolved by app server restarts is a result of service initialization issues post-migration. After discovering this, we are tightening startup validation checks to prevent this from happening.

The MES URL routing issue in Pilot is being addressed. We’re making sure “?mode=DC” is part of the URL to access Data Collection.

…Still with me???..

Now to address the questions and comments about testing. Yes, we tested the migration process.

However, this migration is not a routine operational task. It is a foundational platform shift. What Pilot exposed was not a lack of testing, but inconsistencies between the validated migration model and how some environments were executed.

We are tightening runbooks and enforcing stricter deployment validation to eliminate configuration drift.

The next step is Production migrations to Linux. We are actively reviewing the timeline based on our findings, and your feedback. We must ensure we have a stable platform first before initiating the Product environment schedule. We have a slow Production migration plan scheduled, on purpose.

Updated timing and communication will be published on EpicWeb and on status.epicor.com, and yes, we’ll explicitly reference Linux migration activities.

For those of you that don’t know, I was a long time Epicor customer – starting in the Vantage 8 days – before joining the Epicor team. I care. I watch your posts. I’m committed, along with Epicor leadership – Arturo, Vaibhav, Steve etc – to fixing our mistakes and working hard to not repeat them again. Please don’t suffer in silence. Create the support tickets. Mention my name if you need to. Escalate the tickets after submitting the case. Escalate the case to your CAM asking to escalate to me. If you aren’t being visible/vocal, we can’t see you (or know you are having issues or concerns.)

In closing, thank you for using this community and not being shy. Epicor Leadership is watching and reading – we just aren’t going to intervene or reply to every subject so this continues to be a user-focused community. We’ll provide updates and responses as needed.

20 Likes
9

Thank you Jen for the candor. We really appreciate you all being active and reading and taking the feedback.

5 Likes
10

Jen,

Thanks for the communication. Looking at some of the pain points on the Pilot migration and thinking about what to do different for the live migration:

  • Can we get more advanced notice? As far as I am aware, nobody outside Epicor had any idea what the specific date was, just that it was coming at some point. Lets not repeat this for the live, please.
  • Can you make sure it doesn’t line up with other testing/upgrade burdens so people aren’t hit with a double wammy?
  • Can you stagger the roll out over a longer period, starting slowly so issues can be found before too many people are affected?
  • Can you have a plan for a rollback if a particular company has a unexpected severe issue?
3 Likes
11

Shouldn’t the next step be, migrate another subset of pilot environments to Linux and verify that this time it works correctly, BEFORE just running it on production and hoping you got it right this time?

Y’all need to relax your release schedule for these massive changes. Who cares about updates every 6 months if every time you do one everything breaks? I would rather not have another update for a year and the next one to be without any of that drama. I’m sure I’m not the only one.

6 Likes
12

+1 to this, can you space things out please.

Rolling out so many changes so quickly, 26.1 / Classic sunset, Linux Containers, etc, all coming in one or two months timeframe is just setting you --and us customers-- up for failure.

6 Likes
13

THIS. We were one of the “subset” of affected Flex1 clients.

Now we’re apparently going to be a Flex2 on 2025.2 with a 3/20 date…even though we asked for an earlier date in March, were told that we could do that last week, now being told we can’t do so.

1 Like
14

@JMPCONJ can you use the self upgrade in CMP?

1 Like
15

We might have to now…and that just got thrown back at us by Epicor as a “solution”.

2 Likes
16

They fixed our MES issue but Azure file-share is still broken.

This has stopped our Linux testing and a major part of our migration testing.
Does anyone who is on Linux have file share working, if so what did Epicor do to fix this. Its been well over a week now and I am not getting new information on the case.

It’s really bad now but not a patch on if this happened in production. They’d be getting thousands of calls.

File writing error: Access to the path ‘/usr/local/app/\{company#}.file.core.windows.net\157173\Live\OCS_2.5X1NonCSticker__2-20-2026_11_58_PM_45.bt’ is denied.

This was functioning before the Linux ‘upgrade’. Now I will have to redo all the Linux testing again once they fix it, just to make sure something else is not broken.

1 Like
17

@Randy didn’t you get it working?

18

Epicor sent me a temporary solution which they didnt explain well.

I need the full fix to continue otherwise I will have to test everything again.

From Epicor:

The issue preventing read/write access to your Cloud‑provisioned Azure File Share in the Pilot environment appears to be caused by the legacy FTP site still being configured for access. In Linux-based environments, the file system interaction functions support only a single shared folder to be mapped to the ServerFolder.FileShare class. Based on testing, when both an Azure File Share and an FTP site are configured in a Cloud environment, the FTP configuration takes precedence.

I have submitted a request to the Cloud Ops team to remove the FTP site configuration from your Pilot environment so that only the Azure File Share settings remain active. I also specified that this change must be limited strictly to the Pilot environment and that no modifications that could impact Production are to be made.

It is something they have to do on their end.

So in Windows you can have both FTP and Azure file-share. But Linux only allows one. When Epicor pushed the Linux container update they set it to FTP which was being retired (at their request).

That message from Epicor is 10 days old which gives a timeframe of how long it takes them to switch it and how long we have had to pause major facets of our Linux and Migration testing.

And just to be thorough this also stops the FTP retirement testing which was supposed to be completed by January 15 - Epicor’s timeline.

image
image299×168 17.4 KB

4 Likes
19

That’s frustrating. hopefully they figure it out soon for everyone.

1 Like
20

I agree.

Based on their other comments its a bigger issue then that.

They are mentioning root cause and this:

The underlying security issue still needs to be addressed, as it is not Linux-specific and should not be deprioritized.

I did ask for a discount. They did not like hearing that.

4 Likes