File Channel Stopped Working

We are on prem

I had a channel that was looking to a folder on the landmark server for a file. It was working fine.

I had other environments using file channels to look at a shared network drive for a file - they all worked fine. I switched the first channel from looking at the landmark server, to look at the shared drive like the other environments. Now the channel does not work anymore .... I've tried cycling the LPA node in the grid, we bounced the server, I've deleted and recreated the file channel (3 times), I've cleared landmark cache, I've tweaked the set up of the channel - like manual vs automatic, time interval, etc.. nothing has worked...I can not get this channel to pick up it's file!

Any experience with this? Any suggestions? I've opened a ticket and so far I've only received "it's not best practice to use a network drive for the file channel". If that is true, why not? I thought that is what this channel was for? I've been using it for years without issue...until today.

Thank you!

Find more posts tagged with

Process Automation (IPA) - General Discussions

Accepted answers

All comments

Legacy Contributor

UNC paths are just fine for FC's. First, since FC's work via FTP, is that File Share location within an FTP site on that server? Does the user you are using for the FC have Full or Modify rights there? Is there a Fire Wall preventing access to that location from the Landmark Server?

jreese

Did you test the connection to make sure the login and password is correct and can access the location of the file?

laura-patenaude

I had a very similar experience a couple months back. Same thing - it was working fine and then it stopped working. I also have several flows that look at network drives without any issues. The ONLY way I could resolve this was delete the File Channel and Receiver completely and then recreate them. But it sounds like you've already done that - I'm curious to know what the issue ends up being. Like I said - I use network drives in the majority of my flows - the rest are lookups on the LSF server work directories. I'm going to go back through my ticket, when I had that problem, and see if they had me try anything else (I also had a ticket open with Infor and they couldn't figure it out which was then that they suggested I delete everything and recreate it).

Legacy Contributor

Next, from the Landmark/IPA server, manually open a FTP session using the user/pw you are using in the FC, to verify that you can get to that location via FTP. If not, it should give you the error you need to troubleshoot the issue.

john-miller

Shared drives are not Officially supported by IPA I believe. Back when we were on prem I ran shared drives like you. I've run into errors where the share no longer works, and found that the shared drive used by IPA is separate from User shared drives. So if you did a net use while logged on, it may be different from the net use by IPA. I created a Process flow that checks if IPA can reach the shared drive, and if it can't it recreates the share. I can share that flow if you're interested.

chris-mccullough

Thank you! Yes, I did...the folder/file is accessible from the server and the "test connection" says it is successful.

chris-mccullough

Awesome - thank you

chris-mccullough

Thank you JD! I'd be interested to see that. I used to create flows that would mount a network a drive via command line , move a file, then unmount that drive. I've moved away from that method and tried to use file channels where possible. So far, I've had no issues with them until this one.

Legacy Contributor

Note: File Channels use FTP site paths not UNC share paths, with files, as it needs to perform the FTP to get the file or read the file. You need to have an FTP site setup on the Source server and an FTP user that has the Full access to that folder at the OS level. The Source folder location can either be its own site or a Virtual Directory within a site that has the folder location with it's defined path.

Example: On my LSF server for IPA FTP & FC use, I created a IIS site called IPA_FTP. Within it, I created several Virtual Directories, and defined the physical path to the root location of the directory path in which it need to begin looking. In this example, Virtual Dir called: PL_Work, is defined to the path to the Production Productline Work directory. I have many subfolders within the WORK directory that we monitor. I have a FTP user granted access to the site and access to this Virtual directory and at the OS level to the Work folder structure. The FC is defined to monitor the "PL_Worksubfoldername" using FTP (or SFTP depending on your setup) protocol and the FTP user defined with the access.

Legacy Contributor

BTW, what was the error the FC/Receiver was giving you?

chris-mccullough

Thank you Michael. That is what's weird...there are other channels hitting the share. For example, I have success:
\sharefolder_Afolder_BFile no prob
\sharefolder_Afolder_CFile not working.

They are using the same security and I can get to and open the file from the server.

chris-mccullough

Michael, if the channel is set to local, it's just looking at share paths...there are no creds to pass. If it was remote, then it would be an FTP situation. But with the local option set, you don't get to enter credentials. Unless I am missing it - let me go look again.

Legacy Contributor

Chris, how are you getting to folder_C for your test, via File Explorer or did you open an FTP session and get into that directory?

What is the exact error that the Receiver is capturing when it errors out?

chris-mccullough

My other file channels look to the same root directory but just a different folder..with no issue. The folders all share the same security, etc.

john-miller

https://community.infor.com/infor-process-automation-product-group/m/infor-process-automation-product-group---media-gallery/1259

chris-mccullough

File Explorer.
That's the bummer...there is no error...there is nothing to start the trail I need to go look in the LPA logs to see if there is something there...

chris-mccullough

Thank you JD!

Legacy Contributor

Ah, did not catch that the "Share" was pointing back to the Landmark server itself. Is your grid running as the Local Lawson user or a DomainLawson user? If running as a local user, then the Local Lawson user will need to have access within the Share security setup.

When you are testing the share access from the server console, are you logging in as the same user as the Grid user or a different user?

john-miller

Seeing your latest screenshot made me think of another Error I've had. I had a bunch of file channels using the same Error, and Processed folder. A ticket I opened with Infor, the resolution they gave me, and it worked, is to make sure each file channel uses a different Error and Processed Folder location.

Also, If you're Reciever is looking for a specific file, make sure that file has Delete access.

chris-mccullough

They for sure have separate folders for inprogess, error. I will go look at the delete access now. Thanks!

Legacy Contributor

As JD mentioned, depending upon which version if LM you are running, there is a bug in which the error folder can only have 20 error files/folders put into it then it just stops working due to it starts the numbering over again and the file/folder that it creates in the error folder already exists.. you have to manually clear those out. I had this issue, but a later LM CU corrected this.

Also, since you are looking at Local folders, it is best to use the explicit local path to the folder instead of a UNC path, as at times, there are network issues that can cause this to happen, as the server will have to jump out into your network then come back to the server to gain access to that share location, performs additional security calls to verify access permissions, etc.

chris-mccullough

This rings a bell! this could be it...let me jump on the server and look at that - thanks Michael!

Legacy Contributor

If the Receiver isn't generating an error, how is your receiver setup? Can you send screen shot if that?

chris-mccullough

folder access looks correct..going to look at the user running grid as well as who is in the AD group on the folder per Michael's suggestion

chris-mccullough

btw, thanks for the help and quick replies! So awesome.
Ok, here is the receiver screen shot. Again, no errors or last scan time...I've tried automatic and manual and neither work.

Legacy Contributor

I have never used a space in the Channel Name or Receiver Name. Could you try it without a space?

Legacy Contributor

I had a similar issue. Infor ended up restarting our LPA grid node. This restart cleared up the issue and the File Channel started up immediately.

Tammy

chris-mccullough

Thank you Tammy. Restarted LPA node just now...no luck, but the log from grid did show this:

2021-03-10 11:45:49,068 -0700Z {} WARN LPA System.err: Warning: Category: ipa, Key: fileChannel.useTimer.<Suffix> can only be used as a prefix and no suffix data was passed in to ConfigurationParameterKey.getExtendedKey(String addtl)

2021-03-10 11:45:49,091 -0700Z {} WARN LPA System.err: Warning: Category: ipa, Key: fileChannel.threadsCount.<Suffix> can only be used as a prefix and no suffix data was passed in to ConfigurationParameterKey.getExtendedKey(String addtl)

bhillz

Best practices question: Have you found it better to use a mapped drive vs fully qualified UNC (i.e. \serversharefoldersubfolder)

Legacy Contributor

Best Practices question of a Local FC, do you use a UNC share path or Local drive path:

If the folder you are monitoring with a LOCAL File Channel is on the SAME Landmark server that your IPA is running on (as you could have multiple LM servers, capability is there), then it is best to use the local drive path, such as E:folderfolder, which in this example is the E: drive on the LM/IPA server itself, where the folder resides.

The user running the grid is what is being used when using Local and "should" have local admin rights and "should" have access to the local drives, unless you have specifically set security for that user to not have rights in that folder location. The traffic to the folder is all local to the Server, not network traffic is used.

If you are using a UNC/Share path of \LMIPAServerfolderfolder, then the Grid user must have access FULL access at the Share Security level and FULL or MODIFY access at the OS/NTFS level in the folder that it is monitoring. Note this traffic DOES go out into your network, comes back thru the Share, performs access validation thru the share and at OS level. Network latency could impact the polling/monitoring of the folder and/or a network blip or issue with DNS entry/response could prevent back to the share from the network. I've had similar happen when network got overloaded or we had router issues, etc., it prevented the bounce back to the server/share.

There are more examples of possible network related issues that could impact it, these are just a few.

russel-cornelson

In Infor Support I've seen this same issue numerous times over the years, enough that my advice with file channels is to avoid UNC shares whenever possible. If you do have to use them, I recommend the same that JD has here using net use to check and recreate. Not sure how you built it JD but I built mine in powershell.

Copyright © 2025 Infor. All rights reserved.