Services typically do not have access to network drives on Windows. You need to run the service as another user - one that has the appropriate permissions - if you want your service to access the network.

As an alternative to Mark's suggestion, you can let the database service run as before and make the database server temporarily connect as another user who has network access.

This is discussed in this answer.

Accessing SMB/CIFS/NetBIOS shares as the standard SERVICE account in Windows with the standard security policy doesn't work. When you log in to a Windows box and map a network drive, the mapping only exists in the logged-in user's context. You didn't log in as SERVICE, so the SERVICE user doesn't see the share you mapped. This is correct from a security perspective. If Jane and John, for example, both log in to the same Windows box at the same time, and Jane maps a network drive, John shouldn't have access to that drive (John himself needs to authenticate himself to the SMB server).

I would suggest the following alternatives:

1. Install a web server on the computer which has the file you want to access, and use a web service client function in the database to access the file.
2. Use a command-line smb client via xp_cmdshell() to transfer the file to the database server before you read it. For example, https://www.leepa.io/lpackham/smbclient/ . Be sure to write a wrapper procedure that calls xp_cmdshell() then xp_read_file() and then ALTER PROCEDURE sp_whatever_you_call_it SET HIDDEN. You will be embedding a username and password in your xp_cmdshell() parameter, so you don't want to leave that visible in the SYSPROCEDURE view.
3. Install Interactive SQL and ODBC on the computer where the file you need to read resides. Set up a scheduled task to push the file into a table or a database-scope variable using read_client_file().

Alternative 2 allows you to make no changes to the file server, so it's probably best for you.