Persission denied on Windows

[t-v]

I have a Windows 2008 R2 machine and keep getting this error:
admatriusy02c:
Traceback (most recent call last):
File "salt/minion.py", line 695, in _thread_return
File "salt/modules/win_pkg.py", line 457, in refresh_db
File "salt/modules/cp.py", line 393, in is_cached
File "salt/modules/cp.py", line 63, in _mk_client
File "salt/fileclient.py", line 42, in get_file_client
File "salt/fileclient.py", line 643, in init
File "salt/crypt.py", line 466, in init
File "salt/crypt.py", line 478, in __authenticate
File "salt/crypt.py", line 320, in sign_in
File "salt/crypt.py", line 213, in minion_sign_in_payload
File "M2Crypto/RSA.py", line 157, in save_pub_key
File "M2Crypto/BIO.py", line 186, in openfile
IOError: [Errno 13] Permission denied: 'c:\users\exh345\appdata\local\temp\2\tmp3kxie9'

So I assume some of the permissions have changed, since previously on client version 0.17.2, this error wasn't present.

These people seem to have the same issue:
https://groups.google.com/forum/#!topic/salt-users/hGHtl8Xc4m0

[t-v]

After also upgrading my master to version 0.17.4 I get this error on state.highstate:
[WARNING ] The minion function caused an exception: Traceback (most recent call last):
File "salt/minion.py", line 695, in _thread_return
File "salt/modules/state.py", line 237, in highstate
File "salt/modules/state.py", line 91, in running
File "salt/modules/saltutil.py", line 365, in is_running
File "salt/modules/saltutil.py", line 399, in running
WindowsError: [Error 5] Access is denied: 'c:\salt\var\cache\salt\minion\proc\20140107110058875000'

and this one on pkg.refresh_db:
admatriusy02c:
Traceback (most recent call last):
File "salt/minion.py", line 695, in _thread_return
File "salt/modules/win_pkg.py", line 457, in refresh_db
File "salt/modules/cp.py", line 393, in is_cached
File "salt/modules/cp.py", line 63, in _mk_client
File "salt/fileclient.py", line 42, in get_file_client
File "salt/fileclient.py", line 643, in init
File "salt/crypt.py", line 466, in init
File "salt/crypt.py", line 478, in __authenticate
File "salt/crypt.py", line 320, in sign_in
File "salt/crypt.py", line 213, in minion_sign_in_payload
File "M2Crypto/RSA.py", line 157, in save_pub_key
File "M2Crypto/BIO.py", line 186, in openfile
IOError: [Errno 13] Permission denied: 'c:\users\exh345\appdata\local\temp\2\tmpslfkxk'

And when I check the access rights there, it's full access for administrators and system, so it should be accessible.

[basepi]

No good! We'll look into this.

[basepi]

Erm, just talked to @UtahDave, and this may already be fixed! =D

[t-v]

Awesome..
And when will the fixed version be available?

[basepi]

I don't know. He was looking into it (to make sure it was the issue he thought it was).

@UtahDave status?

[UtahDave]

They are kind of related. I just finished working with s0undt3ch to fix a couple other bugs that were keeping me from getting to this one. Getting to it now.

[juso]

Actually I face the same issue, but cannot recognize the pattern - I installed salt-stack on fresh windows few dozen times already, and sometime it works right away, sometimes it exposes the error above, sometimes it shows completely different errors. Trying to categorize things before opening new issue.

[juso]

That's another issue I receive in 0.17.4 (when I don't bump into the above issue), not sure if it's related to the original problem, add it here just because they are sort of complimentary, when I see one, I don't see another and other way round. Let me know if I need to create a separate issue in github:
09/01/14 15:39:26,741 [salt.state ][INFO ] Executing state file.recurse for c:\xxxxxx 09/01/14 15:39:26,741 [salt.crypt ][DEBUG ] Loaded minion key: c:\salt\conf\pki\minion\minion.pem 09/01/14 15:39:26,866 [salt.crypt ][DEBUG ] Decrypting the current master AES key 09/01/14 15:39:26,866 [salt.crypt ][DEBUG ] Loaded minion key: c:\salt\conf\pki\minion\minion.pem 09/01/14 15:39:26,960 [salt.fileclient ][DEBUG ] Fetching file ** attempting ** 'salt://os/windows/disk_c/xxxxxx/file1.ps1' 09/01/14 15:39:26,960 [salt.fileclient ][INFO ] Fetching file ** done ** 'os/windows/disk_c/xxxxxx/file1.ps1' 09/01/14 15:39:26,960 [salt.state ][ERROR ] An exception occurred in this state: Traceback (most recent call last): File "salt/state.py", line 1305, in call File "salt/states/file.py", line 1655, in recurse File "salt/states/file.py", line 1578, in manage_file File "salt/states/file.py", line 1157, in managed File "salt/modules/file.py", line 2161, in manage_file File "salt/modules/file.py", line 1699, in check_perms NameError: global name 'set_mode' is not defined

[t-v]

I had that one too, but for some reason it got fixed after reinstalling the minion.

[juso]

I thought so as well, and by re-intalling salt-minion I sometimes I manage to get rid of this problem, but since I'm working on the deployment process it's not one off, and next time I try to run exact same setup it gives me this error. Somehow since I decided to automate pem/pub keys distribution to salt-minion and to migrate to 0.17.4 it's become a disaster, I experience different kind of issues with no obvious pattern. And sometimes it just works. Weird.

[t-v]

Can' say about multiple machines, since we're just starting to use Salt on our Windows environment.
So that one machine was our pilot case. But yes, I already tried reinstalling it, to get rid of that error.
But next to that, nothing changed, since it's a scripted install, so the config will be identical every time I install it.

[UtahDave]

I found several issues during my testing yesterday. I fixed a couple of
them, but the trickier issues that are still outstanding were caused by
some changes in how modes are handled on Linux. When they made the changes
they didn't keep Windows in mind. In still sorting that out.

In the past I've just had the windows minion ignore "mode" and let the file
just inherit whatever default permissions the target folder gives it.

Should we try to convert mode into icacls? Should we continue ignoring
mode? Any other thoughts on this?
On Jan 9, 2014 7:56 AM, "juso" notifications@github.com wrote:

I thought so as well, and by re-intalling salt-minion I sometimes I manage
to get rid of this problem, but since I'm working on the deployment process
it's not one off, and next time I try to run exact same setup it gives me
this error. Somehow since I decided to automate pem/pub keys distribution
to salt-minion and to migrate to 0.17.4 it's become a disaster, I
experience different kind of issues with no obvious pattern. And sometimes
it just works. Weird.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/9604#issuecomment-31938576
.

[juso]

I can't comment on this, for me would be good enough the way it was before (just copying files and applying default permissions) - I take care on permissions separately if required. And it's not very clear to me how to convert linux permissions to windows ones, in this situation I would avoid messing around with those even if the mechanism is available.

[juso]

BTW, tried to re-run salt-call after the previous issue with set_mode, and I got this error:

IOError: [Errno 13] Permission denied: 'c:\\salt\\var\\cache\\salt\\minion\\highstate.cache.p'
Traceback (most recent call last):
  File "<string>", line 6, in <module>
  File "__main__.py", line 128, in <module>
  File "__main__salt-call__.py", line 14, in <module>
  File "salt/scripts.py", line 77, in salt_call
  File "salt/cli/__init__.py", line 303, in run
  File "salt/cli/caller.py", line 135, in run
  File "salt/cli/caller.py", line 78, in call
  File "salt/modules/state.py", line 261, in highstate
  File "salt/state.py", line 2379, in call_highstate
  File "salt/utils/__init__.py", line 903, in fopen
IOError: [Errno 13] Permission denied: 'c:\\salt\\var\\cache\\salt\\minion\\highstate.cache.p'

The file 'c:\salt\var\cache\salt\minion\highstate.cache.p' appears to be r/o, if I change it to r/w and re-run salt-call - then I'm back to the prevoius 'set_mode' issue. Hope this shed some light on where the problem is.

[UtahDave]

OK, this PR, #9656, will fix the problem with set_mode and some other related problems with managing files.

[t-v]

I'll try that when I'm back at work
On Jan 9, 2014 9:41 PM, "David Boucha" notifications@github.com wrote:

OK, this PR, #9656 #9656, will
fix the problem with set_mode and some other related problems with managing
files.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/9604#issuecomment-31973844
.

[juso]

I don't mind trying this one, just don't know how to get hold of the fix - is there an install file somewhere or a patch I can apply?

[UtahDave]

If you installed your minion with the windows installer, you can clone the
repo and drop the contents of the salt directory into your minion's salt
directory. You can find that if you poke around inside c:\salt\ I can
get you the exact directory location later today if you don't find it.

On Thu, Jan 9, 2014 at 2:47 PM, juso notifications@github.com wrote:

I don't mind trying this one, just don't know how to get hold of the fix -
is there an install file somewhere or a patch I can apply?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/9604#issuecomment-31980262
.

Dave Boucha | Sr. Engineer

Join us at SaltConf, Jan. 28-30, 2014 in Salt Lake City. www.saltconf.com

5272 South College Drive, Suite 301 | Murray, UT 84123
office 801-305-3563
dave@saltstack.com | www.saltstack.com http://saltstack.com/

[t-v]

This is the location I dropped it in:
C:\salt\salt-0.17.4.win-amd64\salt-0.17.4-py2.7.egg

Testing it as we speak

[t-v]

this seemed to generate:

[WARNING ] The minion function caused an exception
Traceback (most recent call last):
File "C:\salt\salt-0.17.4.win-amd64\salt-0.17.4-py2.7.egg\salt\minion.py", line 747, in _thread_return
return_data = func(_args, *_kwargs)
File "C:\salt\salt-0.17.4.win-amd64\salt-0.17.4-py2.7.egg\salt\modules\state.py", line 237, in highstate
conflict = running()
File "C:\salt\salt-0.17.4.win-amd64\salt-0.17.4-py2.7.egg\salt\modules\state.py", line 91, in running
active = salt'saltutil.is_running'
File "C:\salt\salt-0.17.4.win-amd64\salt-0.17.4-py2.7.egg\salt\modules\saltutil.py", line 368, in is_running
run = running()
File "C:\salt\salt-0.17.4.win-amd64\salt-0.17.4-py2.7.egg\salt\modules\saltutil.py", line 410, in running
os.remove(path)
WindowsError: [Error 5] Access is denied: 'c:\salt\var\cache\salt\minion\proc\20140108110317812000'

[t-v]

on the otherhand, test.ping works and so does pkg.refresh_db.
which is an advancement, since the last one failed before.

[juso]

Dave, I tried to run the exact same setup on 0.17.2, and in roughly 30% of attempts it gives me another error (other 70% run fine):

10/01/14 10:29:22,441 [salt.minion      ][DEBUG   ] Parsed kwargs: {'__pub_fun': 'state.highstate', '__pub_jid': '20140110102922441000', '__pub_pid': 2716, '__pub_tgt': 'salt-call'}
10/01/14 10:29:22,441 [salt.log.setup   ][ERROR   ] An un-handled exception was caught by salt's global exception handler:
UnpackValueError: 
Traceback (most recent call last):
  File "<string>", line 6, in <module>
  File "__main__.py", line 128, in <module>
  File "__main__salt-call__.py", line 14, in <module>
  File "salt/scripts.py", line 77, in salt_call
  File "salt/cli/__init__.py", line 303, in run
  File "salt/cli/caller.py", line 135, in run
  File "salt/cli/caller.py", line 78, in call
  File "salt/modules/state.py", line 237, in highstate
  File "salt/modules/state.py", line 91, in running
  File "salt/modules/saltutil.py", line 365, in is_running
  File "salt/modules/saltutil.py", line 392, in running
  File "salt/payload.py", line 95, in loads
  File "_unpacker.pyx", line 119, in msgpack._unpacker.unpackb (msgpack/_unpacker.cpp:119)
UnpackValueError

I posted it here because it may have something to do with the original issue as after some investigation I realized that if I delete the cache files from here 'c:\salt\var\cache\salt\minion\proc' then it runs forward without probs and Timothy posted the log above (second post) showing some permission problems in this exact location. Let me know if I need to create a separate issue in github.

[juso]

It looks like a separate issue, I raised it here #9673

[juso]

I got the HEAD revision using this command (let me know if it's not the right one, I'm nood in git)

git pull
git checkout origin/HEAD

And the results of trying to run salt-call are stranger than ever:

[INFO    ] Loading fresh modules for state activity
[INFO    ] Executing command 'attrib -R "c:\\salt\\var\\cache\\salt\\minion\\highstate.p"' in directory 'C:\\Users\\Administrator'
[INFO    ] output: File not found - C:\salt\var\cache\salt\minion\highstate.p
local:
----------
          ID: states
    Function: no.None
      Result: False
     Comment: No Top file or external nodes data matches found
     Changes:
              ----------

Summary
------------
Succeeded: 0
Failed:    1
------------
Total:     1

After returning to 0.17.2 all run fine. Probably I'm not applying the right patch or not applying it correctly.

[UtahDave]

Yeah, I'd recommend deleting the entire contents of the c:\salt\var\cache\salt\minion\proc\ directory

[UtahDave]

@timothyvandenbrande, could you uninstall the Salt Minion, make sure c:\salt\ is deleted and test with this new build? http://docs.saltstack.com/downloads/Salt-Minion-0.17.4-3-AMD64-Setup.exe

Thanks! Let me know how it goes.

[t-v]

I will do that 1st thing tomorrow, since ATM I don't have access to the
machines.
On Jan 12, 2014 7:19 AM, "David Boucha" notifications@github.com wrote:

@timothyvandenbrande https://github.com/TimothyVandenbrande, could you
uninstall the Salt Minion, make sure c:\salt\ is deleted and test with this
new build?
http://docs.saltstack.com/downloads/Salt-Minion-0.17.4-3-AMD64-Setup.exe

Thanks! Let me know how it goes.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/9604#issuecomment-32116312
.

[jpoppe]

@UtahDave I just encountered the same issue after playing with salt and Windows 8.1 Pro (64 bit) today,
http://docs.saltstack.com/downloads/Salt-Minion-0.17.4-3-AMD64-Setup.exe fixes the issue for me 👍

[t-v]

@UtahDave I just installed this version, and it seems to have fixed my issue.
tyvm

[t-v]

There sitll seems to some minor issue, but this isn't as severe and not blocking:
#9711