Hi Janez,
what about specifying allowedReadPaths accordingly?
Did you restart the IS after specifiying the parameter?
Some parameters require a restart of the IS.
Regards,
Holger
Restart was done a few times. Still not working
Thanks & Regards
Janez
Janez, can you check whether you have access on fileAccessControl file, also can you involve your Unix team to check any permission issues.
Thanks,
See if this helps:
The behavior of pub.file:getFile is controlled by the watt-parameter.
That is because the file permission checking is the intended behavior in order to prevent the IS from overwriting arbitrary files on the O/S.
All pub.file:* services are supposed to do this, only pub.file:getFile was missed with the initial implementation of this functionality.
When this service was updated to check the file permissions, they made this behavior for pub.file:getFile configurable in case sites relied on the old (incorrect) behavior.
Customers can switch off permission checking for pub.file:getFile, but the best option (and the way all pub.file:* services are intended to work) is to have permission checking enabled and permissions configured using the fileAccessControl.cnf file.
See if this helps:
The behavior of pub.file:getFile is controlled by the watt-parameter.
That is because the file permission checking is the intended behavior in order to prevent the IS from overwriting arbitrary files on the O/S.
All pub.file:* services are supposed to do this, only pub.file:getFile was missed with the initial implementation of this functionality.
When this service was updated to check the file permissions, they made this behavior for pub.file:getFile configurable in case sites relied on the old (incorrect) behavior.
Customers can switch off permission checking for pub.file:getFile, but the best option (and the way all pub.file:* services are intended to work) is to have permission checking enabled and permissions configured using the fileAccessControl.cnf file.
See if this helps:
The behavior of pub.file:getFile is controlled by the watt-parameter.
That is because the file permission checking is the intended behavior in order to prevent the IS from overwriting arbitrary files on the O/S.
All pub.file:* services are supposed to do this, only pub.file:getFile was missed with the initial implementation of this functionality.
When this service was updated to check the file permissions, they made this behavior for pub.file:getFile configurable in case sites relied on the old (incorrect) behavior.
Customers can switch off permission checking for pub.file:getFile, but the best option (and the way all pub.file:* services are intended to work) is to have permission checking enabled and permissions configured using the fileAccessControl.cnf file.
Thank you all very much
It is important which OS you are using. So if you use \ or / in File Access Control configurationi file.
And in case of Linux path is case sensitive.
If all settings are done correctly than reload of wmPublic package is enough.
And also pesrmissions on file system has to be appropriate
It is working now
Thanks & Regards
Janez
Yes you have learned and shared important notes here and this could very help other’s in the similar case issues: 
HTH,
RMG
@Janez - Does your issue got resolved ? I am facing this issue now, could you please advise here ?
Hi,
it is true that the path on *nix is case sensitive.
But the type of path separator is OS-independent when using “/” (regular slashes).
These will work on either *nix or Windows OSes.
To separate different entries for one permission, use “,” (semi colon) as a separator.
Remember to reload WmPublic package after modifying the WmPublic/config/fileAccessControl.cnf file.
Relative pathes are relative to IntegrationServer/ directory or IntegrationServer/instances// directory (depends on version).
Regards,
Holger
All the steps below mentioned are already tried out PFB details
I am stuck with below issue and not able to resolve it, could you please guide me providing some advice on this ?
I have a flow service to
- Get data from local DB
- MAP ? DOC
- DOC ? XML string
- XML string ? File ? using built in service pub.file:stringToFile to write a file.
However I get below error when this service is executed:
Error:
com.wm.app.b2b.server.ServiceException: [ISS.0086.9263] Specified path [F:\SAG9.12\data] is not on the [allowedWritePaths]
allowed list in the fileAccessControl configuration file
Steps I tried to resolve this:
- Edited fileAccessControl.cnf key – value properties (F:\SAG9.12\IntegrationServer\instances\default\packages\WmPublic\config) as shown below & reloaded the wmPublic package & restarted IS couple of times.
a. allowedWritePaths=F:/SAG9.12/data/cust.xml
allowedReadPaths=F:/SAG9.12/data/cust.xml
allowedDeletePaths=F:/SAG9.12/data/cust.xml
b. allowedWritePaths=F:\SAG9.12\data\cust.xml
allowedReadPaths= F:\SAG9.12\data\cust.xml
allowedDeletePaths= F:\SAG9.12\data\cust.xml
c. allowedWritePaths=F:/SAG9.12/data/cust.xml
allowedReadPaths= F:/SAG9.12/data/cust.xml
allowedDeletePaths= F:/SAG9.12/data/cust.xml
Other Details
webMethods installed version : 9.12
OS : Windows 7
fileAccessControl.cnf path :F:\SAG9.12\IntegrationServer\instances\default\packages\WmPublic\config
pub.file:stringToFile : filename (variable) value – Tried different possibilities like F:/SAG9.12/data/cust.xml , F:\SAG9.12\data\cust.xml, F:/SAG9.12/data/cust.xml
Hi Girish ,
Please end every path added in the fileAccessControl.cnf with “;[Semicolon]” and try.
Hi,
please have a look at the IS Built-In-Services Reference, chapter named “File Folder”.
In the intro of this chapter there is a description of the fileAccessControl.cnf incl. samples.
As far as I can see your examples a and c above are identical.
According to the Built-In-Services reference example b is incorrect.
Regards,
Holger