I can do that.  For future queries, I'm getting these 4 errors in the Audit Database for each error:

Description: Attempt to access a protected resource
Reoutine: EMSUpdatePassword+2^%SYS.SECURITY |"^^c:\intersystems\ensembledev\mgr\"|
Namespace: {namespace}
Event Data: <PROTECT>EMSUpdatePassword+2^%SYS.SECURITY *c:\intersystems\ensembledev\mgr\

Description: Attempt to access a protected database
Routine: Store+5^%ETN |"^^c:\intersystems\ensembledev\mgr\cachelib\"|
Namespace: {namespace}
Event Data: <PROTECT>Store+5^%ETN

Description: Attempt to access a protected database
Routine: Value^%STACK |"^^c:\intersystems\ensembledev\mgr\cachelib\"|
Namespace: {namespace}
Event Data: <PROTECT>Value^%STACK

Description: Attempt to access a protected resource
Routine: ^%SYS.SECURITY |"^^c:\intersystems\ensembledev\mgr\"|
Namespace: {namespace}

I'll ask IS.



We've been using the $SYSTEM.Security.ChangePassword since 3/2017, apparently, and only recently have I noticed that it's logging a <PROTECT> error, and yet still changes the user's password (only recently have users been required to change passwords):

<PROTECT>EMSUpdatePassword+2^%SYS.SECURITY *c:\intersystems\ensembledev\mgr\"  at  8:27 am.   $I=|TNT||11696   ($X=0  $Y=26)
     $J=11696  $ZA=0   $ZB=$c(13)   $ZS=262144 ($S=268247904)
     source   code not available

I'm using this line of code: 

set bChanged = $system.Security.ChangePassword($username,newPass,oldPass,.ok)

bChanged is not in the error trap; ok =1; the user's password is generally changed, as far as I can tell, because we don't get users asking why they cannot log in.  I can recreate this from the terminal using a username without much acess (no %SYS access).

I'm sure there's a security thing going on here.  Why would this error get logged?  It makes me nervous, as we're adding more users who will need to change their passwords often.

Any ideas?

I can't compile or step through the code - it's hidden.



A task, of course... I'll have to go through the list of users and check their LastLoginTime/CreateTime, Enabled, etc.  For future users who are looking for this, I'll use the SQL procedure Security.Users_Detail().

I did not know about the Security.Scan, but I'll take a look, and see what else I should tack on to it.  Good idea to run our custom security task after the SecurityScan.

Thanks! Getting there.  And perhaps InterSystems will add this concept in the 2017 (2018?) release.


Ha!  That was it.  Thanks.  Wish we had entered all our usernames in one case, but alas.  

Thanks for the help - I appreciate all the answers.  Now, to go through our security and update all the appropriate roles.... 

I am not sure.  I'll check now.

Edited to: I wish I could paste an image, but this may be the problem.  I granted my laura_test_dev user

1. direct permission to execute

2. the %Library.File_FileSet SQL Procedure,

3. in the PMG namespace.   

Logged out of the terminal, logged back in as that user, and got this:

Username: laura_test_DEV
Password: *********
PMG>w $system.SQL.CheckPriv("laura_test_dev","9,%Library.File_FileSet","e","PMG")

I agree; this seems like it should work, and for some reason that I haven't yet figured out, it is not working.  At this point, the folder structure and who created the folders has no bearing.  We're on version 2016.2.2.

MISSED A CRITICAL STEP.  I then ran the query from the terminal, after having given that user the direct permission, and the query worked.  Now I'm confused as to why I got a 0 on the priv check, but the query worked.  But, it worked.  So maybe I won't mess with it.

We do have auditing turned on, for all kinds of events.  I was looking at that, and didn't see much that I could use.   Scratch that -- we happen to have %System/%DirectMode/DirectMode events turned on, and I could only see the fact that user Laura_test_DEV ran that command line in the terminal, but the Details page doesn't show failure or any more info.

Didn't think to debug the %PRepare method.  I can probably see what line of code is actually failing.  The other "low-level" (as I think of it) call to FileSetFunc works at the terminal prompt, but I'm not sure if it's working from the application.  I can only hope it has something to do with the test folders.

Thanks for the help.  I'll update with my final solution.

From the terminal prompt, logged in as my application user, the ##class(%File).FileSetFunc(directory) appears to be working.  Oddly, giving the user execute permissions like John suggested didn't work.  I wish it had because my code is all set up for the class query.

I had seen the FileSestFunc in other posts... I don't know why this works differently.  Can I use a FileMask, however?  

set rs=##class(%File).FileSetFunc("c:\","*.pdf;*.csv")

Oh, and we're on Windows, and the instance is running as a domain user with lots of privileges, but if the application user copies and deletes a file, who is actually doing it?  The instance's user, or the application user?

Too early for me.

Also, I did try the call with a FileMask, and it does work.  Is it the same as the FileSet query?  I can't find it in the code... must be a lower-level call to that query or something.  

John, thanks for the info.  It was indeed a windows security problem, related to the new Cache_Instance_instancename group.  I had created 3 namespaces before we ran the cinstall (windows-level caché command to set up the windows security needed), and then because they were located outside of the cache tree, lost access to them.

Note: this was a very special case where I installed the new instance to run as the local system, and then needed to run the cinstall command to change it to use another windows domain user.  We also ran into a few windows security issues after the upgrade that we're still working out.


We rectified it by added the appropriate security to the e:\ drive where the dataset are located.


Also note: I created a test namespace AFTER we ran the command to set up the windows security (i.e. today, I created it), and the caché service user DOES automatically get access to the folder with the new dataset.


Thanks for all the speedy help!


Hello John,

I'm trying to get more information about a similar $ZF issue, and running the caché instance as a Windows user rather than Local SYSTEM.  I have this link from IS to help me out: 



But I was hoping to get a little bit more info from the link you sent out; unfortunately the link gives me a "missing" error.  Do you think you can find that link again?


This is my issue: after we upgraded from 2014 to 2016, the ability to use call out (such as w $zf(-1,"dir *.*") ) is gone.  IS recommended using the cinstall command, as noted above, but it's not working.  I'm asking IS about it now... We run our instances under a particular user, not as local system.

I can update this thread with the solution.


Laura Cavanaugh