Generate clickable link to a location on a file server

I’m looking to enable my users here to select a folder or file on our file server ( Ventura SMB ), generate and then share some form of functional text that when clicked by the recipient can open the selected folder or the selected file’s container. I can find no method of doing this.

In lieu of this, I can take the selection and generate an AppleScript app using OSACompile that contains a shell script that opens the target. Of course a lot of tools currently used for inter-office communication won’t transfer the resulting AppleScript. I’m looking at you Teams!

Does anyone here know of any method of generating any functional link or other data/app/etc that can be shared with other users that will reveal a location on a mounted macOS file server?

Is your difficulty arising specifically with generating links for a file resource on a mounted/remote volume (which would imply you are able to accomplish this for a file located on your boot drive) ? Or is the fact that it’s a mounted volume not relevant to the problem, and it’s about generating clickable links to file resources generally ?

1 Like

That’s a good question, @CJK.
But, @paulskinner, if you don’t need to worry about the “network volume not mounted” situation, you could give everyone a little AppleScript that takes the file currently selected in the frontmost Finder window and makes a “file” URL for it. Actually, this sample code takes the selected files (might be more than one) and makes a return-delimited list of “file” links. When a user clicks one of these links (and has the necessary volume mounted), the Finder should open the enclosing folder and highlight the file/folder specified by the link. If you want this to ALWAYS return a single link for whichever file is the 1st in the selection, you could add as “exit repeat” line before the “end repeat” line to only get a single link into the clipboard. But, it might not be clear which selected file/folder will be “1st”, so the code behavior below of getting them all is probably best.

tell application "Finder"
	-- get the selected files/folders: 
	set selectedItems to selection	
	-- convert to an AppleScript list of file links: 
	set fileLinks to {}
	repeat with oneItem in selectedItems
		set oneFileAlias to oneItem as alias
		set oneFileLink to "file://" & POSIX path of oneFileAlias
		set end of fileLinks to oneFileLink
	end repeat
end tell
-- save delimiters, then convert list of links to return-delimited text:
set {oldDelims, AppleScript's text item delimiters} to {AppleScript's text item delimiters, return}
set fileLinks to fileLinks as text
-- restore delimiters:
set AppleScript's text item delimiters to oldDelims
-- put the list into the user's clipboard:
set the clipboard to fileLinks
return fileLinks

Note: There could be a potential wrinkle where it looks like the volume is “WhateverMyNetDriveIs” in the Finder, but behind the scenes it is mounted at this POSIX path: “/Volumes/WhateverMyNetDriveIs 2” (or 3, or 4, or so on).
If that happens, then users are accessing the same network drive, but the file links they share with each other will fail, since their paths are different. Hopefully your network isn’t having that issue. I think it is related to some Bonjour flakiness.

As that also happens with SMB/CIFS volumes, I doubt that. It’s just one more flaw of Apple’s networking stack.

1 Like

Fair enough. I forgot it hit those types of network volumes.

File URLs are functional, ish, but I have to percent encode them to handle any spaces in the path.

In, clicking these File urls generate a “Grant File Access” dialog. Clicking its “Select” button brings up a sheet which offers a “Grant Access” button. Once for each unique link. :[ Not fun, but not horrible.

Teams styles them as links, and you can choose “Open link…” Nothing happens, but you can choose it. Same with meh!

I currently generate posix path(s) as return delimited text for the users to share. These are at least manually locatable, or they can be pasted in to the “Go/Go To Folder…” menu to reveal the target.

In a past OS the contextual menu offered “Reveal In Finder…” when an posix path was selected. Not so in Ventura. I suppose coding myself a new contextual path-revealer might be a good option. Maybe make it support HFS, Posix and file://

Reveal in Finder could be done with unix command: open -R

* This is the path to copy manually "~/Desktop" next run the script
* Result: Finder will open new window with the path

set filePath to the clipboard
do shell script "open -R " & filePath

That’s not “Unix”, but macOS. In Unix, there’s only an open() system call (see man 2 open) which opens a file when called in a C program.

The term Unix is family of operating system. Like XNU, Darwin and BSD…
Apple’s macOS is: Single UNIX Specification, Version 3 that is same as POSIX.1–2001
It use Unix shell that is command-line interpreter (CLI) to execute commands.

Its fine if you like to call it macOS but its doesn’t change the above.

open as a command (aka program) is not part of the POSIX specification. It is only available on macOS. Not in any other Unix variant. Which makes it, in my book, a macOS command. The shell is completely irrelevant in this context, btw.

1 Like

Here is draft what Apple is supporting

It doesn’t say anything about new implementation of commands running in Unix shell.
But it say many things how the implmentation should be done to follow the standard.


If the command talks to device it needs to follow the standard. The same it would do for other Unix operating system. If an command is ported to Unix operating system it needs to follow the standard. It doesn’t matter if Apple make an command that is not find else where. Its still Unix command becouse it follow the standard to be called Unix operating system.

I’m not sure if t was a template or standard service. But I have a Finder service when right click on a finder item. The service is called “Copy Path”,

Let me investigate the workflow and get back to you. It could easily be adapted to create a NSAttibutedString

  • ➊ You can coerce the selection to an alias list to save doing it one-by-one:

    set selectedItems to the selection aa alias list
  • ➋ Did you know that both Finder and System Events can return a file URL for a file or folder on the disk ? As @paulskinner noted, a file URL typically needs to be percent-encoded, but Finder and System Events do this for us:

    set oneFileLink to the URL of oneFileAlias

which will yield a string similar to: "file:///Users/CK/Documents/A%20Text%20File.txt".

Both of these will improve performance, though the percent encoding is clearly the biggest advantage:

tell application id ""
        set fs to the selection as alias list
        tell a reference to fs to repeat with f in it
                tell f to set the contents to the URL
        end repeat
end tell

set my text item delimiters to linefeed
set the clipboard to fs as text

@paulskinner didn’t ever make it clear whether the issue was purely around generating file links, or obtaining an appropriate file path to a network resource. For the latter, the NSURLResourceKey item called "NSURLVolumeURLForRemountingKey" will provide the actual e.g. smb:// file URL (from which you can retrieve its absoluteString())…

1 Like

That is true. But the term “Unix command” refers to the core set of commands that come shipped with all Unix installations. These will run on all Unix systems by virtue of their adhereence to the POSIX standard. @chrillek is correct in saying that open is not a Unix command, both in the sense that it is not in the list of The Unix Commands, and also in that it’s specific to BSD systems (it was initially written for and appeared in NeXTSTEP). Commands like open wont necessarily adhere to the POSIX standard (I dont know off the top of my head whether it does or not), so wont work on other systems without adapting in some way, or it may do but with different results (e.g. killall).

Honestly, there might be enough going on here that it could be worth you building yourself an AppleScript applet (or a pair of them).

You could essentially make your own custom URL format that covers your needs, but preface it with a custom URL protocol. Perhaps almost the same as the “file:” protocol, but “filexyz:”, where xyzzy is your organization’s acronym… Then, have your AppleScript applet register as the owner of that custom protocol. Not all apps will automatically format that as a link, so folks would have to copy it, but then you could have the “Open Link” AppleScript stay-open applet automatically check the clipboard when it is activated. It then converts the filexyz link into a normal file link, and people would only have to Grant Access the first time they use the applet (or a new version of it).

The “Create Link” applet could use what @CJK suggested, but then change the “file:” at the beginning to your “filexyz” equivalent.

Someone did something similar using AppleScript back in 2005:
OS X URL handler to open links to local files - I think a few things have changed since then, but the general idea is the same. To set the CFBundleURLSchemes in the Info.plist, follow the instructions at CFBundleURLSchemes, since the 2005 post’s links about that have gone 404.

Making your own applet that handles a custom URL protocol can take a bit of work, but then you have a lot more control over how it works.