# win\_chocolatey using unc path in source

**URL:** <https://forum.ansible.com/t/win-chocolatey-using-unc-path-in-source/29264>\
**Category:** Ansible Project\
**Created:** [December 14, 2018, 1:01pm UTC](https://forum.ansible.com/t/win-chocolatey-using-unc-path-in-source/29264 "2018-12-14T13:01:19Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Serge\_Zajac](https://avatars.discourse-cdn.com/v4/letter/s/d2c977/32.png) [@Serge\_Zajac](https://forum.ansible.com/u/Serge_Zajac)\
**Post date:** [December 14, 2018, 1:01pm UTC](https://forum.ansible.com/t/win-chocolatey-using-unc-path-in-source/29264/1 "2018-12-14T13:01:19Z")

</div>

Hi cheers,

I’m not able to use a share or unc path in the source parameter of win\_chocolatey module  
The same is running if you use choco directly with cinst -y myPack --source “\myserver\myshare”

I’ve opened an issue on github ([https://github.com/ansible/ansible/issues/49871](https://github.com/ansible/ansible/issues/49871))

they allready answer that it was supported… but i’ve never seen examples running fine.

I don’t know what is wrong as i use a user which have the rights to access the share.

- name: deploy LogPoint  
win\_chocolatey:  
name: myPack  
source: \myserver\myshare  
state: latest

can anyone experienced the same thing ? I’ve also seen a post here on which there were doubts about the support of this solution…

---

<div class="post-metadata">

**Author:** ![jborean](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/jborean/32/1525_2.png) [@jborean](https://forum.ansible.com/u/jborean)\
**Post date:** [December 14, 2018, 9:48pm UTC](https://forum.ansible.com/t/win-chocolatey-using-unc-path-in-source/29264/2 "2018-12-14T21:48:18Z")

</div>

Hi

The source parameter can be used to specify a file path to some package, we even used to use that functionality in the integration tests for the module. The ‘source’ module option is used with the ‘–source’ argument as shown by [https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/windows/win\_chocolatey.ps1#L166-L169](https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/windows/win_chocolatey.ps1#L166-L169) so it has the same rules and supports the same features as the command line.

What you are most likely coming across is the double hop/credential delegation issue as Ansible runs the task through WinRM. When using WinRM (or other network logons), the user’s credentials are typically not accessible to the running process so it cannot then authenticate with different servers like a file share. In this case it will try and access the share as an anonymous user which results in either an access is denied or file not found error. Compared to when you run it locally, the process has access to the user’s credentials and can authenticate as that user for downstream server implicitly.

Microsoft have a detailed guide on this here [https://blogs.technet.microsoft.com/ashleymcglone/2016/08/30/powershell-remoting-kerberos-double-hop-solved-securely/](https://blogs.technet.microsoft.com/ashleymcglone/2016/08/30/powershell-remoting-kerberos-double-hop-solved-securely/). Ansible has also documented this issue such as [https://docs.ansible.com/ansible/latest/user\_guide/windows\_winrm.html#limitations](https://docs.ansible.com/ansible/latest/user_guide/windows_winrm.html#limitations) and [https://docs.ansible.com/ansible/latest/user\_guide/windows\_faq.html#why-can-i-run-a-command-locally-that-does-not-work-under-ansible](https://docs.ansible.com/ansible/latest/user_guide/windows_faq.html#why-can-i-run-a-command-locally-that-does-not-work-under-ansible).

So to get this task working you have a few options available to you;

- If in a domain environment, use ‘ansible\_winrm\_transport: kerbros’ and ‘ansible\_winrm\_kerberos\_delegation: True’ to enable Kerberos auth with credential delegation
- A special Kerb ticket is sent to the server which can use that ticket for further authentication
- You can configure this to be constrained to only work for certain downstream servers in AD if you wish
- This is the most secure option as no credential is actually sent to the server but a special kerb ticket but it still has some limitations where become is more suited towards the task
- Use ‘ansible\_winrm\_transport: credssp’ after enabling CredSSP auth on your Windows host
- This works the same as Kerberos but works for local account but this is unconstrained delegation- Use become[1] on the Ansible task
- As well as running it in a process that has access to the user’s credentials it also changes the logon type from network to interactive
- This can solve other issues when it comes to installing certain programs or hotfixes  
Using become is probably the easiest and it’s quite simple to do;

`

- name: deploy LogPoint  
win\_chocolatey:  
name: myPack  
source: \myserver\myshare  
state: latest  
become: True  
become\_method: runas  
vars:  
ansible\_become\_user: ‘{{ ansible\_user }}’  
ansible\_become\_pass: ‘{{ ansible\_password }}’

`

What that task will do is run under become and set the become user to the current Ansible connection user with it’s password. Give that a try and see how you go.

Thanks

Jordan

[1] - [https://docs.ansible.com/ansible/latest/user\_guide/become.html#become-and-windows](https://docs.ansible.com/ansible/latest/user_guide/become.html#become-and-windows)