I copy customers' database folders so I can have an exact copy to work from for support. This is especially useful if I am using any ID references. I don't copy the History or the Journal. HisFiles and DataFiles only get copied if I have anything in them.
I was just making a little program to copy database files into a zip file to make it a little faster process. I just noticed that since I upgraded to GeoSCADA that I cannot access database folders that it creates. any database folders that I have that existed before the upgrade I have full access. I think I was on 2017R2 and skipped 2017R3.
If I create the folders before starting the database then I have access permissions.
I know I can force the issue as an administrator but that just a pain in the butt. The Irony is if you access the permissions it shows administrators are the owners and they have full permissions.
Does anyone know if this is this something new to how GeoSCADA creates these folders, or coincidently something Microsoft has snuck in on me?
I get Everyone does not need to be able to access some folders, but preventing administrators from accessing them I find stupid. You are an administrator, and if a hacker has gotten administrative privileges then they can force access to them anyway.
Solved! Go to Solution.
I noticed this back in the beta and it appears we can view/modify the files but we have to "grant" ourselves permission first. I assume this is expected behavior due to how Windows handles permissions. Is that correct?
Workflow:
So in short, the secondary "confirmation" seems to be more of a Windows process than anything CS related. Is there anything that can be done to enforce the permissions so that the prompt isn't required provided you have proper permissions?
Edit:
May have just answered my own question.
From Geo SCADA 2019 the ACLs of database files should have ACLs added only for the users and groups that should be permitted to modify them (e.g., LocalSystem and Administrators).
See https://www.se.com/ww/en/download/document/SEVD-2019-344-05/
In Geo SCADA 2019 the "What's New" section of the online help contains a section called "Access Restrictions to Geo SCADA Expert File Locations" which contains more information on the changes to the default access control lists for Windows folders.
I noticed this back in the beta and it appears we can view/modify the files but we have to "grant" ourselves permission first. I assume this is expected behavior due to how Windows handles permissions. Is that correct?
Workflow:
So in short, the secondary "confirmation" seems to be more of a Windows process than anything CS related. Is there anything that can be done to enforce the permissions so that the prompt isn't required provided you have proper permissions?
Edit:
May have just answered my own question.
Well spotted Trent - good find on the ms site. Interesting that Windows spins a bgd proc to assign permissions.
I got off on other stuff but recently I did work on my program some more.
I don't have UAC turned on but I still get this prompt, so it is something deeper than UAC, or in Windows 10 and the equivalent Server versions, you can not really turn UAC completely off. Which I am beliving is the case as I also cannot install some custom drivers anymore without also selecting "Run as administrator".
I remember this vaguely from the beta now. I was working when I should have just gone to bed.
Also, Explorer had gotten off in the weeds somehow because it was not prompting me at all until I launch an Explorer session using "Run as administrator." In the morning I had the bright idea of restarting the computer. That cleared the no prompt issue up.
If I use "Run as administrator" on my little program it does get access to the files, if I have not gone through the effort of granting my user permanent access.
Discuss challenges in energy and automation with 30,000+ experts and peers.
Find answers in 10,000+ support articles to help solve your product and business challenges.
Find peer based solutions to your questions. Provide answers for fellow community members!