Hi @wolfst 

For repository type Shared you do not need to define the Repository address and user parameters and you keep the Repository Address field blank. It is there only for repository type FTP. Also make sure that the user that runs IFS MWS has read/write access to the path that is given as the shared folder.

In the windows explorer of the IFS Application Server we also installed a network folder called “Q:\” it linked to the document server “\\Servername\”

If this \\Servername is a network share then try giving that path directly in the Repositories window as \\Server\path and give enough permission to IFS MWS user to access it. If this is an FTP server then try to create a new repository with type as FTP and give all other necessary information. 

PS: The Repository status should be “Generating” and not “Usable” in order to actually use it.

Thanks

A few additions to what @Amila Samarasinghe already replied:

1. Although you should not set up a username and password for shared repositories in IFS Applications 10 and earlier, it will be a requirement in IFS Cloud. This can be useful to understand if you will upgrade at some point.
2. On IFS Applications 10 and earlier, where we support “drive letter paths” (like Q:\… in your case), but in IFS Cloud we will only support paths on the format //server/share (IFS Cloud runs inside small Linux virtual machines, also known as containers, and the concept of drive letter does not exist there). Also, Shared repositories in IFS Cloud is not supported in our managed cloud offering, you can only use them in the “Remote” option, when you host the installation yourself. Same goes for FTP support.
3. When you use a “drive letter path”, it’s important to understand that, the drive should be defined on the application server, where MWS runs.

For Apps 10 and earlier, I would recommend using FTP instead of Shared repositories since I think it is easier to setup the access that way, it’s more explicit. Of course, it requires the additional complexity of a FTP server, but it’s a stable technology with many server options, both free and paid.

Good luck!

Hello Amila,

thank you very much for the answer!

Another hint for all who have a similar question. First release the complete drive for all users and then write a file there via IFS. The user which must be corrected afterwards is not the Windows user, but a technical IFS user, which you can see then over the permission of the file.

Many Thanks!

@wolfst 

Good trick you used there, finding out the user

Another way is to change the user that runs the MWS to a domain user you have control over, and only grant access for that user.

I assume it works now, correct?

Yes, it works perfectly.

Dear @wolfst,

I have the same issues regarding check in into shared folder.

Can you elaborate more on the statement below:

“Another hint for all who have a similar question. First release the complete drive for all users and then write a file there via IFS. The user which must be corrected afterwards is not the Windows user, but a technical IFS user, which you can see then over the permission of the file.”

What do you mean by “write a file there via IFS”? Does “Technical IFS User” means IFS MWS default administrator (ifs in this case) or else?

Thanks for your help.

Regards,

Roby Wong

Hi @RobyWong 

“write a file there via IFS” might mean check in a document via IFS so that it will be saved in the folder, and then by examining the file properties figure out the user which created it. Usually “ifs” user is the one who runs MWS so have you tried giving read/write access?

Thanks

Thank you sir, for the hint. I finally worked it out. See below screenshot. 

Best Regards,

Roby Wong

excellent @RobyWong  and also @Amila Samarasinghe 

Please find more information from below screenshot. This is from the share folder server point of view.

Hi Everyone

How do You resolve problem that all environments(production, test, etc) pointed the same shared folder? Do You change settings after copy production environment for example to test environment?

It is very risky that someone from test environment would remove attachment - I mean physical file shared in common directory.

Hi @knepiosko 

It is not recommended to use the same shared folder for production as well as any other test environment.  After a production copy to a test you can always change the basic data settings such as document ticket temp path and repository address etc.

Thanks

It would be great if we could use substitution variables in shared folder path: D:\shared_docs\#DB_SID# or just instance variable D:\shared_docs\$INSTANCE_NAME