Postgresql Unable To Write Inside Temp Windows 10
Renzo Hayami
As I was finishing off my question above, our IT chap turned up and knew what the problem was immediately: it's McAfee. It prevents anything from running in a TEMP folder, including Windows Scripting Host scripts. Disabling McAfee for the duration of the installation fixed the problem for me.
Well, in my case nothing worked, and disabling McAffee needed a special ticket with my company's security team to actually do... so I installed using the binaries, by following this guide Helpful Guide.
In summary, download the binary from here, unzip it, go inside the pgsql folder, create log and data directories in there, and then open a command prompt, navigate to where the pgsql\bin folder is, and run initdb -U postgres -A password -E utf8 -W -D POSTGRESQL_ROOT\data
In my case it was another application that caused the problem. Not Notepad++. To others who encounter this problem, you can diagnose it by first deleting all files in C:\Documents and Settings\UserName\Local Settings\Temp so that you'll be able to find the bitrock_installer.log easily when you try installing postgresql again and view the instructions in it. Changing the (Default) key in the HKEY_CLASSES_ROOT, .vbs section of the registry to VBSFile solved it.
My problem was Smad-Av which disables Windows Scripts from running,Only after going through this thread i remembered.I just right clicked the Smad-Av icon and selected Allow Windows-Script & Office-Macro (Permanent).
I had the same problem with installing PostgreSQL (Unable to write in TEMP environment variable path), the problem was in Windows Script Host which was disabled (check the log file to see if this is your problem). enable it with register editor (run-->regedit) at this location Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings by setting its value at 1
Solved it by following my gut and changing the User Temp folder to the same with the system's : Win + Pause/Break to have the Computer Properties window appear (you can do that manually by right-click on Computer icon on Desktop -> Properties) -> click on Advanced System Settings on the panel on the left -> click on Environment Variables andunder "System variables" - Variables, find the TEMP and TMP ones and copy their paths. Then, under "User variables for Administrator" - Variables, find the TEMP and TMP ones and paste the paths. It's most always "C:\Windows\TEMP" anyways ;)
Security Essentials, McAfee did not restore the registry paths ("not my problem"), and the McAfee DLL, of course, was removed from the location during uninstall, so the vbscript.dll registration in fact pointed to NOWHERE and NOTHING.
There has to be a better way to write Antivirus software so that it doesn't disable the user's operating system when it is uninstalled, or when featuresare turned off, or replace registration. See the following:
If you see a dialog box called "Windows Script Host Settings", WSH is enabled, and your problem with PostgreSQL installation must be related to something else. If you get an error box that says "Windows Script Host access is disabled on this machine. Contact your administrator for details", WSH is disabled, and your problem with PostgreSQL installation may be related to it (or may be not).
For me, my problem was related to Windows script. I resolved this by right-clicking on smadav icon in the hidden icons in the task bar and checked "Allow Windows-script and Office-Macro (Permanent)". Then double click on the PostgreSQL setup again.
This happened to me as well. Turned out I couldn't use a Domain user (even though it is an admin on the local machine). I had to log in as a local admin user, and then the installation worked. This is very weird.
I tried installing Postgresql-9.5.19.1-windows-x64 version (downloaded from official page) on Windows 10 x64 and it gave me the same error. I tried executing it with administrator privileges, giving permissions to the temp folder, moving temp folder to another location but nothing worked...
In my case e.g.: I removed the /data folder from the (Windows 10) [Drive]/Program Files/PostgreSQL/11 and as soon as I uninstalled version 11.2 and reinstalled (earlier removed 12) version 12: when I started pgAdmin4 my former servers ([nameA] and [PostgreSQL 11] and databases nd the new server [PostgreSQL 12] were there! And the connection was reestablished
For me, problem was that some files inside Data folder of existing Postgres installation had cleared permissions & ownership information. I was able o fix the problem by going one level up above Data directory and re-setting the Owner of the child directories & files via standard Windows dialog. After that, re-running installer allowed icacls to set permissions & finish the installatio nsuccesfully.
Apparently this happens if you uninstall PostgreSQL and do not delete the "data" directory where your databases are stored. When you attempt to (re)install PostgreSQL, it fails to change permissions on that directory, because it already exists. I was able to work around this apparent bug in the installer by deleting all of C:\Program Files\PostgreSQL manually. But that might not be an option if you have data in there that you haven't backed up.
After stopping the setup the pg - service was removed and rights in pg-data / base - folder were missing.We run takeown /F d:\PgData12\* /R /A and startet the setup again. Then it worked without other problems.
For me, on Postgre 16.3 installer, the problem was that the installer log, which can be found on Windows at '%temp%\install-postgresql.log' said that it tried to create a local user account with the same name as my domain account, and then it tried to set inheritance on the installer temporary folder in %temp% and icalcs could not do that, it failed. My solution was to rename the existing local account that I wasn't using to something else.
I'm the guy who posted about Win 7 64 bits... I just saw your updated post and i see that my problem is "related to somthing else".
I must say that I updated the temp and tmp path to c:\temp
when I try to install, I see new files in the temp folder, so I guess the installation finds the folder and can write to it...
But still not found the solution...
Regards.
Works like a charm on Win7 32-bit. I have an ugly feeling that this might be something specific to Win7 64-bit. I do not have access to a box with 64-bit Win7 to try to re-create the problem.
I would run the installation, let it fail and carefully examine the Windows error log (that's where I found the WSH problem).
Sorry, guys.
Hello, still not working on my win 7 pro 64bits.
Even if I set full rights to everyone on the temp folder.
I can't even find one solution on the web... could anyone help finding the solution?
Thanks
We're trying to use cygwin to install postgres 9.0 silently on Win 2008 R2 and we ran into this issue too with the TEMP env var error. WSH was enabled on our systems, so that obviously was not our solution
In the end, we believe it to be an issue with the TEMP environment variable. It's defined in Windows/DOS, but not in the cygwin shell where the postgres installer is launched.
This was fixed in our environment by issuing an "export TEMP=/tmp" (or your other favorite temp directory -- C:\Windows\Temp also worked) in cygwin prior to installing postgres, which gives it a valid TEMP directory to use.
Theoretically you should be able to install it on Vista, but I cannot verify that since I don't have (and have never had) a machine with Vista. Sorry!
Another option you might want to look into is to use a PostgreSQL virtual appliance (say, using vmWare or something) unless, of course, you absolutely have to run PostgreSQL on Vista.
Hi, I asked for help a few days ago, thank you for the answer. I already solved the problem, I had to reinstall my antivirus because it showed me a blank screen when i tried to open it, so I couldnt disable the firewall.
Regards.
I am glad you've solved the problem. It is unlikely that the firewall was the culprit though. I'd rather blame some kind of behavior blocker, which your antivirus may use. Mine screams like crazy every time I install or update anything. However, most antivirus programs with behavior blocking, by default, don't show any error messages and just block things they consider suspicious silently, and then it's a real pain in the butt trying to figure out what caused the failed install.
Found this forum page which down the page a little tells you to get rid of an old erroneous "(default)" McAfee registry entry and put in another correct value. This works like a charm as I was able to get my PostgreSQl 9.x going on my Windows 7 64-bit.
It's pretty easy to fix the problem, just have to eyeball in on the correct line in the registry and change the permission on that one entry folder and change the words on the (default) value
The EnterpriseDB guys gave me a link to one of their pages, I entered the error msg in their search box which found it.
The updated solution fixed the issue: "Unable to write inside temp environment variable path".
Im using Win 7 64 bit, DWORD 64 does not exist in the Windows Script Host/Settings instead you can use QWORD 64 and call it Enabled. That fixed the issue for me.
Versions of the server are not tested on new operating system versions that are released after a newer major version of the server was released. For example, Windows 7 was released after PostgreSQL 8.4, so PostgreSQL 8.3 will not be supported on it. Similarly, when the upcoming RHEL 6 is released, only PostgreSQL 9.0.x will be supported on it. We aim to support new versions of Windows in the PostgreSQL major version following their release at the latest.
PostgreSQL requires functionality that is not available on theseplatforms and will not run on them. If you need to run PostgreSQLon these platforms, you can look at the Cygwinport, which has basic support for 9x platforms.
d3342ee215