Rep Address: CompanyName Rep User: ActiveDirectory-LogIn on the server Rep Password: ActiveDirectory_Password on the server
In the windows explorer of the IFS Application Server we also installed a network folder called “Q:\” it linked to the document server “\\Servername\”. Wie can write files via Windows to this network folder.
But when we upload documents we get the following message “Failed to upload file to the file system repository [Das System kann den angegebenen Pfad nicht finden]”
other this error message: “Failed to upload file to the file system repository [Zugriff verweigert]
The uploaded document are still saved in the IFS-Database but not on the shared folder.
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.
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.
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.
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.
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.
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.
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.
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.
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?
“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?
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.
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.
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
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.
