SQL Server accesses external resources under:
- impersonation, if the original login is an NT login
- service account, if the original login is a SQL login w/o a mapped credential
- credential, if the original login is a SQL login that has a mapped credential
So the user which actually accesses the share will depend on how you logged in to SQL at the moment you issued the RESTORE statement. Note also that if NT login is used then normal constrained delegation rules for impersonation are in place (aka. 'kerberos double hop', if your original login occured on a different LSA than the one hosting the SQL Server service and the target resource resides on a host different from the SQL Server service host then you'll be authenticated by the target resource's LSA as 'anonymous' unless you explicitly configure delegation for that resource).
PS. SQL Agent adds 'proxies' to the mixture, but those are nothing else but credentials (case 3 in my list). See Create a SQL Server Agent Proxy.