I have searched almost many posts and articles. But not helping me with this.
I'm trying to add permission to the $APPDATA\MY_APP\conf directory. I have observed the command is not working properly with multiple machines.
Any suggestions, as to why this below command is behaving differently on 2 different laptops? Both laptops are having Windows 10 Enterprise and Windows 10 Home edition. What mistake am I'm doing?
SetShellVarContext all
;Before Permission
nsExec::ExecToLog '"icacls" "$appDataDir\conf"'
Pop $0
AccessControl::GrantOnFile "$appDataDir\conf" "(BU)" "FullAccess"
;After Permission
nsExec::ExecToLog '"icacls" "$appDataDir\conf"'
Pop $0
Laptop 1: Working on this laptop. The "Users" option is visible on the folder level.
Laptop 2: It's not working on the laptop, I can see on folder permission also "Users" is not visible.
Thanks in advance.
Edit:-
If I add this below permission manually its works fine. How to add only this below permission on NSIS?
Related
I have a problem since yesterday, I made the error of uninstalling Nodejs to put the latest version (14.17.2 LTS OR 16.4.1 Current) and since I have this error ... I do not understand, this is my personal pc and I am the admin (normally) I do not understand either how to solve this problem and in the meantime I can no longer work ...
I've been looking for solutions since yesterday but can't find what I need to do to fix it ..
(PS: excuse my English, I'm French)
I attach you the capture of my administrator account
Windows 10
Error Nodejs
administrator account
MAJ 06/july/2021:
I finally managed to cheat the thing, downloaded the Nodejs ZIP folder, and put it straight to my hard drive and it worked.
Open Command Prompt (cmd.exe) as administrator and type or copy/paste:
net localgroup /add "Authenticated Users"
Then click the "Retry" button or run the installation file again.
I created an NSIS installer that requires elevation and also installs some files in the users AppData directory. This works fine as long as the current user is an administrator. If the user is a limited user then they must run the installer as an administrator, passing the admin credentials to the installer. This all works great except for the fact that NSIS installs the files to the admin users AppData directory in this case. This is because I have been using the $PROFILE variable to determine where to install the files but $PROFILE returns the path to the user that is running the installer and not the user who is logged onto the system.
So to be clear, if User A is a limited account and User B is the admin account, when I log into the computer with User A and run the installer, passing the credentials for User B, I can only ever get User B's username from NSIS and therefore cannot install the necessary files for User A.
I am currently using NSIS v2.49, which I haven't updated in over 2 years so I assume it is quite outdated. At the time of writing, the NSIS site on sourceforge has been down for a few days so it has been difficult to find a current copy of the software. I am open to upgrading to NSIS v3.x if anyone can point out how this may help solve this issue.
Here is some very simple code demonstrating my problem. If you build this installer and run it on a limited users desktop it will demonstrate 3 different attemps to get the currently logged in username, but all 3 will bring back the name of the user that is running the installer instead:
Outfile Test.exe
RequestExecutionLevel admin ;Require admin rights on NT6+ (When UAC is turned on)
!include LogicLib.nsh
Function .onInit
UserInfo::GetAccountType
pop $0
${If} $0 != "admin" ;Require admin rights on NT4+
MessageBox mb_iconstop "Administrator rights required!"
SetErrorLevel 740 ;ERROR_ELEVATION_REQUIRED
Quit
${EndIf}
MessageBox MB_OK $PROFILE
System::Call "advapi32::GetUserName(t .r0, *i ${NSIS_MAX_STRLEN} r1) i.r2"
MessageBox MB_OK "User name Test 1: $0"
ReadEnvStr $0 "USERNAME"
MessageBox MB_OK "User name Test 2: $0"
FunctionEnd
Page instfiles
Section
SectionEnd
Is there no way that an NSIS installer can determine the logged in users username when running the installer as another user?
This is just how UAC works.
If you require elevation then you are doing a machine/all users install and you should only write to $ProgramFiles and HKLM. Add SetShellVarContext all to your .onInit function to prevent writes to user profiles. You should also disable the run checkbox on the finish page.
If your application needs data in $AppData then the application should copy the template data from $ProgramFiles, ProgramData (SetShellVarContext all + $AppData) or $COMMONFILES to $AppData the first time a user runs your application. This has been a requirement in the Windows logo program since at least Windows 2000!
You can find these recommendations in Certification requirements for Windows desktop apps or the older Windows Logo requirements documentation:
10.3 Your app data, which must be shared among users on the computer, should be stored within ProgramData
10.4 Your app’s data that is exclusive to a specific user and that is not to be shared with other users of the computer, must be stored in Users\%username%\AppData
10.6 Your app must write user data at first run and not during the installation in “per-machine” installations
When the app is installed, there is no correct user location in which
to store data. Attempts by an app to modify default association
behaviors at a machine level after installation will be unsuccessful.
Instead, defaults must be claimed on a per-user level, which prevents
multiple users from overwriting each other's defaults.
I'm trying to programmatically copy major folders from C: to E:, for the purpose of automatically backing these folders up. It seems to me, as Administrator, I should have full access like root does on Linux, especially for only reading files.
This makes no sense to me. I'm logged in as Administrator, I run powershell as administrator, and I even went to the Control Panel and moved the UAC slider thing all the way down.
So why am I getting access/permissions errors when trying to copy C:\Users or 'C:\Program Files'?
This will get migrated hopefully, but the answer is that Windows is not like Linux. The Administrator account is not like the root account. It does not, by default, have various rights unless you do the equivalent of a sudo, which is to run the prompt at an elevated rights. Right click on your powershell prompt and choose Run as Administrator.
Dragging the UAC slider down does not turn off UAC, it just turns off the UAC warnings when something wants elevation.
During web application creating i got below popup message:
"Visual studio does not have permissions to read the template information from the registry. this is often caused by registry permission problem."
Any one have any solution?
Please help me. i wana to see Visual Studio new features.
Thanks
this might be quite late as an answer, but I excpierienced the same problem and I found the solution on a msdn page : here is the original solution message :
I came across this issue with Visual Studio 2010 and Windows 7. I did not find this problems source as of yet but, I have found many Visual Studio users encountering it. I tried Michael's solution to this problem and it did more damage then anything else. It even went as far as to make Visual studio to boot into "Shell mode" and tell me the registration was not valid.
Using System Restore I rolled back the changes made by the subinacl tool and Michaels script (it probably was not meant for Windows 7, causing the errors in the first place) .
being a long time visual studio user and a pretty good trouble shooter, I knew the subinacl was the proper tool to correct the problem, but the script was incorrect for my perticular setup. I adjusted the script as follows: (this is a batch script)
cd /d "%programfiles% (x86)\Windows Resource Kits\Tools"
subinacl /subkeyreg HKEY_CLASSES_ROOT\VisualStudio* /setowner=domain\user
subinacl /subkeyreg HKEY_CLASSES_ROOT\VisualStudio* /grant=everyone=f
/grant=administrators=f /grant=system=f
pause
I tried to include the "setowner" command with the grant commands (on the same line) but it would throw errors all the time.
This script fixed MY "Requested registry access is not allowed" with Windows 7 and Visual Studio 2010.
if you want to try this script: Follow Michael's instructions, but use the script provided in this post and replace the "domain\user" with the proper credentials. You may also need to change the Path of Windows Resource Kits if you installed it in a diffrnet place or are not using a 64 bit OS. Before using this script please backup your registry.
I hope that that helped!
*the original web page was : http://social.msdn.microsoft.com/Forums/en-US/c273b0e1-7f46-4065-afaf-4edf285d2531/vista-wpfapplication-requested-registry-access-is-not-allowed
I had this problem too. Followed the post by user2698666 without success. Stuck Process Monitor on it and found there were more registry entries causing a problem called WDExpress. Thought I'd post my fix incase anyone else has same problem:
subinacl /subkeyreg HKEY_CLASSES_ROOT\VisualStudio* /setowner=domain\user
subinacl /subkeyreg HKEY_CLASSES_ROOT\VisualStudio* /grant=everyone=f /grant=administrators=f /grant=system=f
subinacl /subkeyreg HKEY_CLASSES_ROOT\WDExpress* /setowner=domain\user
subinacl /subkeyreg HKEY_CLASSES_ROOT\WDExpress* /grant=everyone=f /grant=administrators=f /grant=system=f
I had the problem with Visual Studio 13, where i wanted to add a webtest project for my newly created solution.
Tried the above trics to set ACL but it didn't work.
Finally used the Procmon.exe to locate what visual studio was doing (Include only process name devenv.exe) and look for result Access Denied. It will tell you what registry key is not accessible.
In my case it was the regkey HKCR.webtest (HKEY_CLASSES_ROOT.webtest) that caused the problem. Taking ownership and assigning acces to this solved my problem.
I do not know how the root cause of the problem.
The above didnt work for me as I kept being denied in regedit even though i was admin.
I found this on another site:
psexec -i -d -s c:\windows\regedit.exe
psexec is available from Microsoft here
http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx
This gave me full registry access. I tried to give admin owner to specific keys like above but VS 2012 express was still throwing that registry permission error. So I finally just added Administrator to the permission list of the entire HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ directory in regedit. Then gave admins full control.
This worked. I can now create a project without that infernal error!
This issue has nothing to do with permissions in the context discussed. The issue is caused by an incorrect path to the template files in the registry due to sloppy installation program testing by Microsoft. The incorrect path throws an error when a user tries to start a new project and, true to Microsoft style, displays a generic and meaningless error message about permissions.
Here's the issue specifically. In some machines (assuming C: is the primary drive and user1 is the user's login name and version 2013) the location of the template files is C:\users\user1\my documents\visual studio 2013\projects. Unfortunately, the installation path written by the installer in the registry is C:\users\user1\documents\visual studio 2013\projects. So, it's pointing to \documents while the correct location is \my documents. To be sure, look where your visual studio 2013\projects folder is located - either documents or my documents - and change the registry key to the correct location.
For my example the key is at HKEY_CURRENT_USER\software\Microsoft\VisualStudio\12.0\NewProjectDialog\MRUSettingsLocalProjectLocationEntries the path is located in the Value0 entry. Check it and change to make it point to exactly where your project folder is.
Lars Meldgard's use of ProcMon was a good tip and helped me. I just wanted to include a picture of what an access denied looks like in ProcMon. I had to do it one registry key at a time--this wasn't the only one. It was very cumbersome and slow, but I was able to knock them off one by one and give full rights on each one. (That part is a hassle too, because I had to take ownership, then close regedit, then go back in so I could set the permissions; you can't do it all in one fell swoop.)
I've installed II7 + ASP Classic on my Vista business pc as I want to develop my own pctools (automate some boring manual tasks).
Unfortunately, every time I try to WRITE into a .txt file I get this error:
Path out = C:\Users\Carlos\Storage\bpmbck.txt
Microsoft VBScript runtime error '800a0046'
Permission denied
/pctools/cleanfb.asp, line 53
Line 53 contains set fileout = fs.OpenTextFile(pathout, ForWriting)
Given that I'm running as an ADMIN and that the target folder is owned by me, I don't understand why this is happening.
I've googled the net to find a similar basic problem (write to a text file) but I only find more complex ones (databases, mail, etc..).
An can anyone help me, please?
The identity/account for the application pool under which the site is running needs to have write permissions to that folder.
This is different from the user you are logged in as.
Give "users" WRITE access to the folder.