Linux Container Migration: Let's Consolidate the Chaos

[Randy (Randy Stulce)]

@chaddb

@Randy didn’t you get it working?

Yes, they didn’t have our ServerFolder.FileShare pointed to our FTP. @tpynepeak seems to be having a different issue.

[Randy (Randy Stulce)]

@JMPCONJ

It’s been a stressful couple of weeks.

Welcome to “On cadence” It’s been fine for years but these last 6-months have been rough. I hope it gets better.

[JMPCONJ (John Magee)]

@Randy

Welcome to “On cadence”

[klincecum (Kevin Lincecum)]

@tpynepeak

In Linux-based environments, the file system interaction functions support only a single shared folder to be mapped to the ServerFolder.FileShare class.

This is the same in Windows based environments as well.

When Sandbox.IO was developed, they were under the impression that you could not have both, while several of us did. Instead of adding another location, they decided to have the ServerFolder.FileShare to be configurable on the backend as to where it points, instead of adding another member to the class. I don’t like that decision, and I think there is an idea out there to change it. @HLalumiere ?

[Evan_Purdy]

@klincecum

I think there is an idea out there to change it.

I looked on the idea portal and couldn’t find anything.

[klincecum (Kevin Lincecum)]

@Evan_Purdy

couldn’t find anything.

Might just be his support case then.

[HLalumiere (Hugo Lalumiere)]

I didn’t create an idea for this, I have been hounding support for 5 months to add a new value to the ServerFolder enum, because it’s not an idea, IT’S A BUG. I still have not been able to get them open a PRB, after 5 months in purgatory, two escalations, and a call to our contact…

It’s a super easy fix. Add ServerFolder.FtpRoot, and map a second path there. One new line in the host config file, and one line of code. Why would you EVER decide that using the same value for two paths is a better idea??

[klincecum (Kevin Lincecum)]

@HLalumiere

IT’S A BUG

But it’s not, it was an intentional decision. I got it from the horses mouth.

[tpynepeak (Tim)]

@klincecum

@tpynepeak

In Linux-based environments, the file system interaction functions support only a single shared folder to be mapped to the ServerFolder.FileShare class.

This is the same in Windows based environments as well.

When Sandbox.IO was developed, they were under the impression that you could not have both, while several of us did. Instead of adding another location, they decided to have the ServerFolder.FileShare to be configurable on the backend as to where it points, instead of adding another member to the class. I don’t like that decision, and I think there is an idea out there to change it. @HLalumiere ?

Weird because our Live system uses both the AZ file share and FTP and they work.
Some of our legacy BAQ exports are still using the FTP file path and our Receiving labels use the AZ Share file path.

Unless Epicor did some wacky stuff on the back end to make it work (which is possible).

I can verify that our BAQ exports ran and posted files last night and that we printed several receipts yesterday as well.

[klincecum (Kevin Lincecum)]

@tpynepeak

Weird because our Live system uses both the AZ file share and FTP and they work.

But not through the Sandbox, you are writing directly.

Sandbox is the only path forward.

[tpynepeak (Tim)]

To clarify for everyone what I said is not working in Pilot. Same setup. It was working until they put the Linux containers in.

On the BAQ Export screen and in the SSRS report style output there is only one place to put the file path.

Whatever solution Epicor proposes has to be clear and by the nines and proven to work before they send it to the customer.

When they sent me the setup for AZ fileshare it was confusing and they did not set up their end so when I tested it it did not work. I had(SSRS Ouput locations, BAQ Export output filenames, BPMS and Functions) until they put in Linux Containers.
Then it all stopped working.

This could not have been tested.

If anything requires yet a another rewrite of my companies functions again that will be an uncomfortable phone call.

[HLalumiere (Hugo Lalumiere)]

@klincecum

But it’s not, it was an intentional decision. I got it from the horses mouth.

The horse is wrong.

[utaylor (Utah Taylor)]

Kinetic got y’all so twisted y’all talking to horses now? @klincecum @HLalumiere?

[bparsons (Billy Parsons)]

Question for anyone that might have EKW…

Is Azure SSO working with EKW for you in Pilot or additional environments?

We are in the beginning stages of this, and just recently attempted to get Azure SSO working (we do have basic to fall back on). We get a very similar Redirect URI error when attempting:

I have completed the necessary steps to add that in Entra, but still no dice. I’m thinking maybe the camel case thing is a problem here, just not sure which letters need to be capitalized.

Might not be though, if anyone else is still able to use Azure SSO for EKW in Pilot after migrating to Linux.

I have opened a ticket with EpicCare that went nowhere, just recently created a ticket on Biscit’s portal. Curious if anyone else is experiencing this though.

Thanks!

[josecgomez]

Redirect URLs are 100% case sensitive. It looks like its asking for

https://emwkineticapp/

Go to your Azure (Entra) find the application that ends in 45f6 and make sure the redirect URL matches 100%

[bparsons (Billy Parsons)]

Looking back… I had a typo.

Working now.

Thanks Jose!

[josecgomez]

Another Linux migration related issue was identified here:
Misconfigured NGINX Proxies

I’ve tagged it in OP, Looks like the NGINX Proxies are misconfigured and do not properly escape URLEncoded content.

Support is aware and working on a fix.

[JillMetalworks (Jill Schoedel)]

My Pilot Database has been stuck since sometime yesterday when they asked:

2026-02-19 17:06:26 -Brad Johnson
What I can gather now is that this is due to having both FTP and AFS (Azure File Share) configured in Pilot. If the goal is to use AFS, then we will need to disable the FTP option for your Pilot system. I didn’t want to submit that request without getting your permission first. Is it OK to move forward with disabling that in just your Pilot system?

---

Our Pilot database is still processing a MetaUIMigration Conversion process since sometime early yesterday. Please do not say “Yes” to this question from support if you get asked to try this as a solution to our FTP fiasco.

Thanks, (apologize for the negativity but this is really frustrating!!)

Jill

[JillMetalworks (Jill Schoedel)]

I put an escalation ticket (system down) on Saturday. Someone from their Tech Support got with this morning to unstick my database. It is now functional but not sure if the Azure File Share is fixed or not. I will report back.

Thanks! (feeling a bit better this morning now)

Jill

[jbooker (Josh Booker)]

@JenTrifty

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

@JenTrifty

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…

Can someone please clarify:

1. which of these is the reason Report Styles having AZ FileShare outputpaths are broken?
2. whether the (/epi/fs) workaround on report style is indeed temporary and
3. whether this was supposed to be fixed in yesterdays emergency SSRS maintenance?