Steinberg Library Manager Move failed, and in the end, did nothing at all

After recently installing all the Dorico-related VSTs to internal drive on a brand new M3 laptop, and having the VSTs take up too much room, I finally got a big external SSD and so, I am attempting to move my VSTs to the external SSD. First, I reformated the new Thunderbolt 3 external SSD to APFS Case Sensitive.

I am receiving dozens of errors from Library Manager for various VSTs, of the form:

Move ‘/Library/Application Support/Steinberg/Content/VST Sound/ADD_SMT_666_Iconica_Ensembles_Presets.vstsound’ to ‘(my volume)/VST_2025’ failed!

And also, the “Remaining Time:” indicated by Library Manager keeps increasing constantly and has reached ridiculous levels, after running for ten minutes now, it is indicating it will take 79h to complete. It seemed to successfully move “HALion Sonic Factory Content” (seems to have been moved first, even though it is not alphabetically first in the app’s window) and Iconica Sections & Players according to the app’s green bar, but there are no files in the SSD’s directory.

Library Manager ‘prohibits’ quitting the app until completion, so, I guess I will have to wait overnight at least, to see what happens. I don’t see why such a move should take much time, given Thunderbolt 3 speeds. …Update… After 20 minutes, even though “Remaining Time:” was indicating over 100h, it ‘finished’ (but actually, moved nothing, as noted above).

:-/

Anyway, the question is, how to I “uninstall” all the VSTi from my internal drive, and instead install them on the external SSD. I do not want VSTi taking up my internal space (which is why I avoided installing any VSTi in the first place). I don’t want them in “/Library/Application Support/Steinberg”.

Additional note… the app did not ask for permission to access the external drive, and macOs Settings show it has access to Downloads and no others listed (can’t add these directories manually in Settings, it seems). If it is permissions-related and it didn’t have permission to Move then I don’t know why it wouldn’t have generated a macOs prompt to access the destination.

It certainly sounds like a permissions problem, i.e. that for whatever reason Steinberg Library Manager cannot write to the chosen location. I don’t personally know enough about the intricacies of permissions in macOS to know why that would be. You could try temporarily allowing full disk access for Steinberg Library Manager before making another attempt at moving the content.

Hi @superblonde , you need to go to the system preferences and in there give the Steinberg Library Manager full disk access.
Similarly as shown here

Ok. That link didn’t work, but I know what you mean. So I granted Full Disk Permissions to the Steinberg apps. I can’t test this fix currently though since I already worked around it in a manual way: I manually moved all .vstsound files (under Application Support in a couple different Halion directories) to the external drive and then double-clicked one of the files in each of the directory to register them recursively in that new location.

The macOs Finder Copy of the 200+ GB’s of VST files only took about two minutes… whereas, Library Manager had previously taken 20+ minutes to try (and fail) to operate on the same files. Whatever Library Manager is doing during it’s Move operation, it is dreadfully, needlessly slow.

Another awkward situation is that the Download Assistant apparently installed “Content HALion 7” directly in my /Users/me/Downloads/Steinberg/OSX directory. Perhaps because HALion 7 was installed after full Iconica, which does something strange to the Download & Install directory preference since Iconica is so big? These numerous “Content HALion 7” .vstsound files don’t show in any Library Manager collection. So I have deleted all of Downloads/Steinberg manually, where nothing should permanently reside anyway.

Maybe (assuming Full Disk Access is not the preferred method of solving this problem, which it probably isn’t) the Library Manager needs to attempt to open the target Move directory before starting it’s Move operation, or something like that, so that macOs will pop up the Grant Permission window, first.

Manually moving many VSTs to external worked except for these which, when registering, and choosing “In Place”, always copy themselves back to internal drive under /Library. What’s going on here - Why would “Tonewheel Organ” and these others be so special as to always copy themselves back into /Library/Application Support/Steinberg? (Now it ends up I have two copies of these files with the same large size, not an Alias, one copy on Internal and one copy on the External SSD.)

Hi @superblonde , you are quite right that the whole installation of vstsound files is quite messed up on your computer. I’m not the author of the installer or the Steinberg Library Manager, but this is how it is supposed to be:
The sound installer also invokes the Steinberg Library Manager who puts the files into place and registers them with the Media Bay, so that they can be found inside Dorico resp. the plug-ins in the VSTAudioEngine.
So the Library Manager puts everything in the default folders underneath /Library/Application Support/Steinberg/Contents.
If you want to move the vstsounds somewhere else, but best do that via the Library Manager’s Move function (the Move buttons on the right of the screen). In you do that LIbrary Manager moves the vstsound file to the new location (whereever that might be) and it the original location it will put a symbolic link to the file in the new place. By that nothing needs to get (re)registered, the Media Bay will find everything by accessing the old.
But in order to move files all over the place, it needs full access to any disk.

Now you know what is supposed to look like.
If I were you , I would completely remove the sound files and reinstall them again, but before doing so, delete the doubled stuff in both locations.

There does seem to be something unique about these particular vstsound files; the files are not listed in Library Manager under any library or any category, can’t reside on External, etc:

The question in that thread is similar to what I also see and is unanswered:

“Is there any way to move these files? They are on my space-limited boot drive and since they’re not in the Library Manager I can’t move them to a secondary drive using that utility…?”

It seems, for mysterious reasons, some of the VSTs (which may not even be sounds) are only allowed to be on the Internal, so, registering them ‘magically’ copies back to Internal if they were on External. Some of these VSTs may be from Cubase installation (and perhaps not the “Content” installation, but the app installation); but, it is impossible to know which file corresponds to which app, or even which library (VST bundle) since this information is not published in any user documentation; and difficult to know which app installed which content, since Dorico is not a Library Manager “category” (not that it should be, which might be more confusing).

Similarly, from Tonewheel Organ and Halion 7 - #8 by Dave :

The issue I have is that is is that I can’t see a way to cross check the sound file with the preset names.

The Library doesn’t show the sound file name FCP_SMT_047_HS_Tonewheel_Organ_01 and the Halion sonic 7 and Halion 7 only show preset names. … I would have thought that there would be a list which shows which program names are associated with which vstsound file. It all feels a little messy as it stands.

I agree with that. A bit messy as it stands.

To bring a little light into the dark, although I’m not the expert on this topic, but here’s a bit of explanation. Vstsound files can hold all sorts of information. First and most important it holds the sampled sounds. This is the raw data so to speak. If you sample a real instrument, you record the instrument at various pitches, dynamics or playing techniques. So you end up with a collection or container of little snippets. In order to play the right snippet at the right time there are preset files. A preset tells HALion which of the snippets to load into memory and to play under what condition (playing technique or dynamic or layer). So a preset may even reference snippets from several containers. To give an example, if you look through the piano sounds in HALion Sonic, you’ll find layered sounds of piano plus strings. In this case the preset will reference sound snippets from 2 different vstsound files. For the user this is all transparent.
And that FCP_SMT_047_HS_Tonewheel_Organ_01 is just the container for raw samples of an electric organ and it does not know by which presets it is referenced. And to be honest, I don’t know how to actually find out.
I also can’t explain why that file always ends up on your internal drive again. You could try moving that tonewheel container by hand (by drag and drop in the file browser or via a command shell) and create a symbolic link back to its original location. If you don’t know how to do that, we could have a remote screen sharing session.

I’m no expert here, but I believe that the Tonewheel organ vstsound file is one of a handful that are considered “essential” by HALion Sonic and so are part of the HALion Sonic application installer rather than the content installer. (This is also true of some of the reverb samples.) That may be why it can’t be moved around like the others.

That could well be, Richard.

Is it possible that the application requiring ‘full disk access’ changed recently? As of Dorico 5.1.70.2200 on macOS Sequoia 15.1.1 I find that I too now see the “Move … failed!” message unless I grant full disk access to the ‘Steinberg Download Assistant’.

Not so far as I know, no. And in any case, it would be Steinberg Library Manager that requires Full Disk Access rather than Steinberg Download Assistant.

I was having the same issue, but I changed granted full disk access to Steinberg Download Assistant. Maybe it’s because Library Assistant is installed with alongside Download Assistant? Library Assistant doesn’t even show up in the Application list in the full disk access menu.

Same issue here, and granting Full Disk Access to Stein Lib Manager didn’t do it, but once I added access for Stein Download Assistant, all worked out… thank you!

Welcome to the forum @CarlMaguire .
And thank you for sharing your experience.

So I just tried to move content to external drive, (using MBAir with very limited internal space). I think it mostly worked as described,

  1. I installed Dorico6 including all content to default locations.
  2. I made sure all the Steinber utilities, downloader, library, etc. have full disk access
  3. I ran library manager and moved them one at a time to my external drive.
  4. I also updated options in library manager so that “default library location” is pointing to my external drive, but I don’t know what is going to do, but that’s where I want my libraries so…

It did succeed in moving everything without any errors and I see that my internal drive is about the usage I would have expected, however on closer inspection I see that the HALion hammond organ did not get moved and actually a number of other VST sounds all adding up to about 1GB are still in /Library/Application Support/Steinber/Content, they did not get symlinked and moved. I see all the symlinks of the stuff that library manager did move.

So it seems library does not or cannot move everything, its still requiring about 1GB of content to remain on the internal drive unless there is something I am missing?

I am curious why can’t we just create one sym link to a “Content” dir over on the external drive and sym link to that in one place? Won’t that work and just leave all library manager and other references pointing to that internal folder that is actually a sym link?

Also wondering if there is any way for me to move the hammond and few other VST sounds off internal to external, including I can do it manually if it makes sense to…but just wondering.

Hi @Dewdman42,
as long as you know what you do and why, of course you can do it. The idea of the Library Manager was just born out of the necessity to give less tech savvy persons a tool at hand, that makes this whole contents management easy and simple. E.g., guess how many users don’t know what a symbolic link is? So to keep this all away from users, we came up with the Steinberg Library Manager.
Regarding 4.) and the “default library location”, of course you can change that, but it will take effect only on the installation of the next Steinberg sound library. That one will then go straight away into your specified directory.
I’m not sure, but the 1 GB worth of contents files still remaining on your internal drive may got installed before the Steinberg Library Manager existed or for other reasons that I don’t know. Perhaps you even pointed those libraries “manually” to the MediaBay. You can do such in the browser area on the right side of the HALion Sonic editor window. So again, you could also move that other stuff out to the external drive as long as you know what you are doing.
It’s just difficult for me to say, do this, that and that, because there is a chance that it messes things up even more, and then you blame me saying:“…but you told me, to do so.”

Do you understand better now?

The 1GB is because library manager is not moving everything. For example moving the sonic selection moves everything EXCEPT for the hammond organ, its missing from library manager’s list and is not moved when everything else is. I consider that a bug. that accounts for roughly 0.5GB right there.

Also the IR’s for the reverb are not moved by library manager.

And then some other relatively small VST files are not moved, but they are relatively small so I won’t worry about it.

I moved the hammond manually and sym linked it, seems to work fine, but who knows what will happen on next update.

I think sym linking the whole Contents folder would probably be easier for even library manager to do, rather then sym linking everything, though there is the option to move your contents all over to different drives, but I imagine most people don’t actually need to do that…so its kind of over engineered if you ask me. Maybe later I will try sym linking just the contents folder to see if everything works fine.

@Dewdman42 , to be honest, I don’t know from which library the Hammond organ comes from, but if you have symlinked it yourself and it works, then that is just fine and no need to worry about future updates.
The reverb IRs are contained in vst-sound archives, but they are not libraries for themselves.
In the Library Manager they appear under the Cubase/Nuendo tab.

Ulf,
I made use of the Library Manager to move sound files to a separate SSD when I set up my most recent computer a couple of years ago. It worked smoothly and continues to work as I install new sounds. Thanks to you and the crew who made this available.

Oh that’s interesting. I have cubase 13 installed and for a minute I tried the cubase 14 demo and then removed it but library manager doesn’t have a cubase tab. Maybe when I removed cubase 14 somehow the library manager configuration got confused about that and removed references to cubase including cubase 13?

The Hammond vst is part of “halion selection”.