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!


Great idea! Yes indeed! this is what it says:

 DKMOUNT: Mounted SFN 5 DB 'e:\datasets\demo\' as Read Only DB. File or filesystem allows read-only access. 

Looks like it's related to our new windows security setup, which, by the way, was implemented as part of the 2016 upgrade.  The 2016 version wants a windows group called Cache_Instance_instancename and the username that runs the instance is moved to this group.  We had to run something to change this windows security after we installed this instance as 2016.  Origainlly, the instance was installed to run as SYSTEM.

I wonder - should I uninstall the instance and reinstall so that it's run as the user?  It's still early enough in the game that I could do that.  Would that automatically give my user access to the e:\datasets\ folder since I'm creating namespaces in the Installer manifest?  not sure.

Anyway, after I've figured out the windows security for this folder, I'll let you know if that helps.


Hi Danny,

That seemed promising, but when I stop Caché, the cache.lck file is removed, and appears again when I restart the instance. 

Yes, the root database name is not the same as my caché system.  Caché is installed in the typical c:\intersystems\instance while these namespaces' databases are on another drive - e:\datasets.  Also, we changed the underlying Windows security recently for our 2016 upgrade, so I'll have to make sure the instance's service user has access to the e:\ drive.

This is what appears in the cache.lck file:



where rhs01p is the instance name, and SERVER01 is the server name.

I'll check the Windows security and let you know.