Hi @feng 

This does not look right:

Read up here on how to set this up:

https://docs.ifs.com/ifsclouddocs/23r1/CreateAndMaintainDocument/AboutDocumentFileRepositories.htm?StandAlone=true

There, search for "Entering a Repository Address and Path". Also check out this process diagram:

https://docs.ifs.com/ifsclouddocs/23r1/ProcessModels/Process_Model/BDRForEDMBasic.htm?StandAlone=true

Seems you missed the first activity there.

Also search for older posts here on IFS Community about getting FTP working, it can be a challenge sometimes. For example, it's not enough that the "middle tier" (k8s cluster machine) can access the FTP server, it needs to work "inside" the cluster as well. And, to warn you, there are sometimes problems with long passwords...

Good luck!

Hi @Mathias Dahl 

Thanks for your kindly reply.

when I changed the Repository Address from “ftp://192.168.xx.99” to “192.168.xx.99”, repository accessed successfully.  Thank you very much.

But when I tried to add a document to a custom order using this repository, an error as below was shown. I searched the older posts on IFS Community, but there is no similar error. Could you give me some advises? Thanks!

Best regards,

Feng

It's hard to say what's wrong,  but it's very clear that the IFS server cannot connect to the FTP server. It can be a network problem (again, the containers inside the k8s cluster must have working network access to the FTP server) or a username/password problem (but I think the error would be different then...). Can you send a screenshot of the Repository User screen? (mask out part of the IP, but please leave the leading and trailing numbers).

Hi @Mathias Dahl 

Thank you for the quick reply. The Repository User screen as below.

I also checked the password rules. Nine characters and no Swedish characters. 

>the containers inside the k8s cluster must have working network access to the FTP server

I want to know how to check it. Thanks!

Best regards,

Feng

Hi @Mathias Dahl 

 

Thank you for the quick reply. The Repository User screen as below.

 

I also checked the password rules. Nine characters and no Swedish characters. 

 

>the containers inside the k8s cluster must have working network access to the FTP server

I want to know how to check it. Thanks!

 

Best regards,

Feng

You need to login to the machine running the k8s cluster and try to use an ftp client from it, to the FTP server.

Hi,

Side comment on this: The k8s is able to authenticate with the ftp server during the ‘Check Repository’ validation on the Repositories page and ALSO during the file upload (where the same check happens before the upload). but the authentication piece when the real file upload happens fails. During the earlier validation, the connection is not disconnected. Could this be something that has to do with the FTP server not accepting parallel connection?

/Deshan

Hi @deshan.ekanayake 

Thanks for you kindly reply.

> FTP server not accepting parallel connection?

Yes, will check it. In fact, in the same environment, file transfers using IFS CONNECT can be performed without any issues.

We are checking the source logic.

Register a user and password for logging in to the FTP server in the menu below.

At this time, the password is encrypted and registered in the DB using the following logic.

For example, if the original password is "ysa@w2ivg", the encrypted password will be "^~b8rD^ux".

But according to the source “DocmanFileOperationUtil.java”, If the password after encryption* contains "^", the logic is not able to retrieve the information correctly. please refer to the logic as below.

String repInfo = getEdmRepository(docClass, docNo, docSheet, docRev, docType, fileNo, connection);

String ftpServerPassword = getStringAttribute(repInfo, "LOCATION_PASSWORD");

By the way, ‘Check Repository’ is okay because the separator of "^" is not used in this check logic. We are going to change the password to one that doesn't contain "^" after encryption and test. will update again. 

Best regards,

Feng

Thanks @feng 

Thanks for bearing with our non-optimal password encryption. We should ideally replace it, but the problem is that it's out there and passwords have been encrypted with it and they are working ... once they are working If we change the algorithm we might need to do data upgrades, forcing customers to update their passwords, which might not always be practical. It's better to try to workaround the limitations, as you are trying there, and adjust the password until you get one that works. Again, not optimal, but it's an option we have...