This problem is plaguing our users and driving management crazy. We have users that are onsite that need to share file locations for files that are on a local server as links in email to other users. They do so by right clicking on the file, clicking get info, and selecting the path from the "Where" section of the file properties.

Some of those users may be connected to the network via VPN, so the afp://appleserver01._afpovertcp._tcp.local in the link doesn't work for them.

We have found that if we manually map a drive using "Connect to Server" or Command+K procedure, using the following:

afp://servername.domain.tld/mountpoint results in afp://servername.domain.tld/mountpoint/filename.txt when we select a file and right click, get info, in the Where section.

afp://ipaddress/mountpoint results in afp://ipaddress/mountpoint/filename.txt when we select a file and right click, get info, in the Where section.

Both of these options are clickable as email links for on-premise users and VPN connected users.

The problem is that if a user opens Finder and clicks on the server name directly without going through the "Connect to Server" or Command+K method, then the "Where" location in file properties when clicking get info is almost always something like afp://appleserver01._afpovertcp._tcp.local/mountpoint/filename.txt, which doesn't actually work for some users including VPN connected users.

How can we force the "Where" location to always be afp://hostname.domain.tld/ always instead of afp://appleserver01._afpovertcp._tcp.local/ when a user clicks on the server in Finder?

What causes this inconsistent behavior?

Edit: This is for Mac OS X 10.11.6 & 10.12.6 (not tested on High Sierra yet).

We are only concerned with files that are stored on a shared resource (server).

  • Please add the system version(s). Also: Info > Where reveals the local path (e.g. /Volumes/Share/file) while Info > Server reveals the whole URI (e.g. afp://servername.domain.tld/Share/file) here (10.11).
    – klanomath
    Sep 28, 2017 at 15:02
  • I edited the original post with Mac OS X versions that we have tested on. Also, we are only concerned with files that are stored on a shared resource, such as a server. Logically, you wouldn't send an email link of a file that was stored on a local resource because the recipient wouldn't be able to get to it anyway. Sep 29, 2017 at 9:19
  • "...you wouldn't send an email link of a file that was stored on a local resource..." Again: Info > Where shows the path to the shared resource from the client's perspective on the client's host e.g a share mounted to /Volumes/Share is /Volumes/Share/file here (not tested on 10.12 but on 10.9 and 10.11)
    – klanomath
    Sep 29, 2017 at 9:46
  • Example (10.9.5 client) from the client's perspective: example file: kali-linux-2017.1-amd64.iso - Info > Where: /Volumes/Share/Linux/Kali Linux 2017.1 x86_64 - Info > Server: afp:// Linux 2017.1 x86_64/kali-linux-2017.1-amd64.iso. I can't reproduce your Info > Where result here.
    – klanomath
    Sep 29, 2017 at 10:01

1 Answer 1


Number one, something might be wrong with your VPN, because everything should work as if you were physically in the office. You might want to check that.

Number two, I assume the remote machines use the wrong IP address when connecting to the servers. And if they are actually successful with some of the tricks you mentioned, you might have a few security issues (maybe caused by someone opening up too much of the network). But I don't fully understand the setup, so take that with a grain of salt.

Number three, I suggest considering a web server with all the necessary protections and storing the files there. Lots of such 'cloud' solutions are available, some for free, also with your own cloud servers, to keep the data local. With some technical knowledge, one can set it up with normal server software, too.

There are three main advantages: Access is possible without VPN access - much safer for some use cases. You can see and control what each person is doing on the server. And you can prepare to make the documents open online, which allows you to keep full control of them - no versions downloaded and then the laptop gets stolen...

  • 1
    #1 reply) I'm not sure that response actually adds anything here. appleserver01._afpovertcp._tcp.local is not resolvable to an IP or other location when connecting via VPN. #2 reply) There is no IP address to resolve. appleserver01._afpovertcp._tcp.local doesn't resolve to anything when a user is remote. #3 reply) Doesn't address this issue. Apr 4, 2019 at 9:16
  • I checked and afp should use IP addresses. Here an article from a few years ago with a similar issue and a solution which might apply to your case: superuser.com/questions/687923/… Apr 4, 2019 at 17:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .