This is absolutely a double-hop issue. The remote computer doesn’t have permissions, by default, to delegate your credentials. You’ll need to take a look at CredSSP.
Edit: I wanted to add more to this post in case you haven’t used CredSSP in the past. The best way to get your feet wet is to use the cmdlets Get-WSManCredSSP, Enable-WSManCredSSP, and Disable-WSManCredSSP. The Get version returns two lines: The first line indicates if the machine, where the command was run, can delegate fresh credentials (think: client). The second line indicates if the machine, where the command was run, can receive fresh credentials (think: server).
In order to use CredSSP, you need to enable fresh credential delegation from your client, and enable receiving credentials on the server. In your instance, your remote computers will be your clients, and the system that holds the UNC share will be you server.
Enable-WSManCredSSP -Role Client -DelegateComputer _________ -Force
Disable-WSManCredSSP -Role Client
The “client version” of this cmdlet requires you specify a computer, or computers, that can delegate your credentials. While you can use * (for all computers), I would opt to be as specific as possible. When I’ve used it, I only allow credential delegation from one system and therefore my command looked like this: Enable-WSManCredSSP -Role Client -DelegateComputer computername,computername.mydomain.com -Force
I entered both the NetBIOS and DNS name because I noticed that if one was entered, and I tried the other, that it wouldn’t work.
Enable-WSManCredSSP -Role Server -Force
Disable-WSManCredSSP -Role Server
Be sure to rerun Get-WSManCredSSP often so you can see how it changes as you use Enable-WSManCredSSP and Disable-WSManCredSSP.
CredSSP can also be set using Group Policy (GP). Once you’re comfortable with CredSSP, you may want to enable credential delegation using GP, especially in a lab environment.