Not able to install LM Runtime after upgrading to version LM Studio 0.3.6 (Build8) under MacOS 15.2 (M4 Apple Silicon)

[Oliver-Fischer]

After upgrading to version 0.3.6 (from 0.3.5) it is not possible to install any LM Runtime. I can download Metal llama.cpp v1.7.1 as well as LM Studio MLX v0.1.3, but they are not installed and therefor it is not possible to run any of my downloaded llms.

[HelpfulScripts]

Exact same issue here.
Is there a link to roll back to 0.3.5?

[yagil]

Hello, please try the following steps:

We think this happens when you run the app from the .dmg window and not from /Applications the first time you run it.

Here's how to solve it (Mac only):

1. close LM Studio, make sure it's not running from the tray either
2. remove it from /Applications on your Mac (i.e. uninstall it)
3. run one of the following commands in your Terminal

If this is the first time you installed LM Studio

rm -rf ~/.lmstudio/extensions

If you've updated LM Studio

rm -rf ~/.cache/lm-studio/extensions

4. Reinstall the app from the installer you downloaded by dragging it into the /Applications folder
5. Open it from the /Applications folder <------ very important

[HelpfulScripts]

Thank you! Removing the extensions in ~/.cache seems to have solved it (I'm prettty sure I started from Applications before)
Loading runtimes now works again; and model loading as well
👍

[namp]

The solution does not work for me. Removed the extensions folder and reinstalled countless times and still the same issue. Runtimes are downloaded but never installed.

M1 Max 64GB, Sonoma 15.2

Hello, please try the following steps:

We think this happens when you run the app from the .dmg window and not from /Applications the first time you run it.

Here's how to solve it (Mac only):

1. close LM Studio, make sure it's not running from the tray either
2. remove it from /Applications on your Mac (i.e. uninstall it)
3. run one of the following commands in your Terminal

If this is the first time you installed LM Studio

rm -rf ~/.lmstudio/extensions

If you've updated LM Studio

rm -rf ~/.cache/lm-studio/extensions

4. Reinstall the app from the installer you downloaded by dragging it into the /Applications folder
5. Open it from the /Applications folder <------ very important

[yagil]

@namp while it's not impossible there's another issue, so far the workaround worked for everyone, so my guess would be you may have missed a step or did not do it exactly. Can you please try again?

[namp]

llama.cpp runtime (1.7.1) again just downloads and does not try to install at all.

However I noticed that mlx 0.1.3 hangs after download with the following error:

Error: Process error: spawn /Users/nikos/.cache/lm-studio/extensions/backends/vendor/_amphibian/app-mlx-generate-mac-arm64@11/bin/python EACCES Command: /Users/nikos/.cache/lm-studio/extensions/backends/vendor/_amphibian/app-mlx-generate-mac-arm64@11/bin/python -I /Users/nikos/.cache/lm-studio/extensions/backends/vendor/_amphibian/app-mlx-generate-mac-arm64@11/postinstall.py Error output:

Nevertheless some files have been created in the extensions dir. The only thing that I can think of as potential source of problem is that my ~/.cache is a symbolic link to an external storage disk

[yagil]

@namp thanks for the extra info. The workaround procedure should solve this exact thing. As I said there may be an additional issue we’re not aware of yet, but I’m currently guessing it’s due to missing a step or not doing it exactly as written

[namp]

Thank you for your support. However there's no doubt that I follow the exact steps as described. I even remove any previous installations in /Applications with AppCleaner so as to make sure nothing remains.

Unfortunately I'll have to revert back to 3.0.5 and hope for a new build which might solve the issue

[yagil]

@namp want to hop on the discord and tag me? I’ll debug with you live https://discord.gg/aPQfnNkxGC

[yagil]

For new folks finding this issue, the fix that works for most people is here: #294 (comment)

[blokhin]

I can confirm simple deletion of extensions folder and restarting the app helps.

[namp]

@namp want to hop on the discord and tag me? I’ll debug with you live https://discord.gg/aPQfnNkxGC

@yagil Much appreciated but I seem to have missed the invitation time window. Please let me know if you'll be available again.

[namp]

SOLVED IT. Indeed the problem was that .cache was a symbolic link to an external drive. As soon as lmstudio was installed from scratch to a real $HOMEDIR/.cache directory, the runtimes were installed.

After installation I reverted back the .cache folder to the external drive and everything seems to be working

[Garblesnarff]

Hello, please try the following steps:

We think this happens when you run the app from the .dmg window and not from /Applications the first time you run it.

Here's how to solve it (Mac only):

1. close LM Studio, make sure it's not running from the tray either
2. remove it from /Applications on your Mac (i.e. uninstall it)
3. run one of the following commands in your Terminal

If this is the first time you installed LM Studio

rm -rf ~/.lmstudio/extensions

If you've updated LM Studio

rm -rf ~/.cache/lm-studio/extensions

4. Reinstall the app from the installer you downloaded by dragging it into the /Applications folder
5. Open it from the /Applications folder <------ very important

This fixed my issue, and the builder was nice enough to point me to this fix from X, I just wanted to post a thank you here as well!

[Ksasa78]

SOLVED IT. Indeed the problem was that .cache was a symbolic link to an external drive. As soon as lmstudio was installed from scratch to a real $HOMEDIR/.cache directory, the runtimes were installed.

After installation I reverted back the .cache folder to the external drive and everything seems to be working

I had the very same issue as well, with symbolic link messing around with yagil's solution, thanks to you, I have fixed in the very same way.

[miranda]

This might be the same bug as mine, but not sure.
#305

My entire home directory is on an external drive. I haven't figured out a workaround, if that is actually the cause. I tried the instructions here but it made no difference.

I could try creating another user account that would be on the internal drive... but seems like this is just going to be a problem going forward if it can't install anything to external drives. The files are there, I've given it Full Disk permission just in case. But I can't load any models and downloading runtimes just resets the button back to "download and install" afterwards.

[ink-splatters]

This might be the same bug as mine, but not sure. #305

My entire home directory is on an external drive. I haven't figured out a workaround, if that is actually the cause. I tried the instructions here but it made no difference.

This issue:

Error: Process error: spawn /Users/nikos/.cache/lm-studio/extensions/backends/vendor/_amphibian/app-mlx-generate-mac-arm64@11/bin/python EACCES Command: /Users/nikos/.cache/lm-studio/extensions/backends/vendor/_amphibian/app-mlx-generate-mac-arm64@11/bin/python -I /Users/nikos/.cache/lm-studio/extensions/backends/vendor/_amphibian/app-mlx-generate-mac-arm64@11/postinstall.py 

is due to python referenced by relative symlink(s) by some reasons does not have executable permissions.

lnk=~/.cache/lm-studio/extensions/backends/vendor/_amphibian/app-mlx-generate-mac-arm64@11/bin/python
chmod +x $(dirname $lnk)/$(readlink $lnk)

fixes it.

In my case, however this doesn't stop lm-studio from keeping on failing for me, e.g. not showing downloaded models.

[miranda]

The solutions here do not work for me. I don't think my issue should have been closed.

I don't even have an lm-studio folder in my ~/.cache, it never gets created. The only thing that gets created is ~/.lmstudio. I have deleted that folder and reinstalled the app numerous times. It does not solve the issue.

Also, LM Studio has no problem showing all the downloaded models. They just can't be loaded by any of the "load model" buttons. They can be selected, and even configured... but load does nothing.

[marlin9993]

it works

[miranda]

I don't know how many times to say this. It doesn't work. I have no lm-studio folder in my ~/.cache. I have followed all the other instructions. It does not work.

This is probably a problem from having your entire home directory relocated to an external drive. That's just how my system is, and a lot of people do this with their tiny 256gb SSD base models, so it should be supported.

[pmarreck]

@miranda Moving your entire home directory to another drive is absolutely an unusual configuration change. What "a lot of people do" in actuality, if they are short on boot drive space, is leave their home directory on their internal drive, and then softlink (or alias, whatever) some stuff from inside their home directory to other drives, because otherwise, booting is literally impossible without that external drive, and that's not a good configuration! What happens if that drive is misplaced, you now have a bricked laptop! No good.

If you moved your home directory since installing LM Studio and it resolved paths on first run to be absolute paths and then it saved that somewhere, then you have an invalid install, because those absolute paths are no longer valid. It can't just look at something like $HOME, because the value of that depends on the logged-in user, and since there is a service/server component which is not supposed to be dependent on runtime/only-while-the-right-person-is-logged-in values, it has to resolve all paths to absolute paths (which are true regardless of who is logged in... Unless it's on another drive, of course!)

So I would say the fix is to uninstall and delete ANYTHING related to LM Studio and then reinstall from scratch. But really, I would first absolutely NOT recommend moving the entire home directory to an external drive, and would recommend reinstating it on the internal drive, but softlinking big stuff (your Steam folder, your models folder, etc.) to the external.

[namp]

Regardless of having the entire $HOME folder pointing to an external drive or just the .cache folder under $HOME as symbolic link (which makes sense given the size of the models) results in failure to install runtimes. This should be fixed!

[miranda]

@miranda Moving your entire home directory to another drive is absolutely an unusual configuration change. What "a lot of people do" in actuality, if they are short on boot drive space, is leave their home directory on their internal drive, and then softlink (or alias, whatever) some stuff from inside their home directory to other drives, because otherwise, booting is literally impossible without that external drive, and that's not a good configuration! What happens if that drive is misplaced, you now have a bricked laptop! No good.

Except Apple supports relocating your home directory, it is configurable that way in the accounts settings in MacOS.

So, I do not agree with this. Sure more people don't do it this way, but it is supported by Apple, and software should not fail from having a setup this way. I have never encountered anything else that doesn't work.

Of course you do not want to do this with a drive that is not always available. But it is the best way to do it if you have a thunderbolt drive that is always connected.

This problem is a bug, and it should be fixed... not ignored just because most people don't set up their system like that.

[freeelectron618]

I had this issue some weeks ago, I deleted the files in the hidden folders and reinstalled (the correct way) and the issue resolved.
Now, the issue is back!
The app is bricked again.

I have a regular installation of macOS (latest).

Downloading and installing the runtimes seems to work, but it does not help.
Running 0.3.9 (Build5)

[yagil]

@freeelectron618 did this happens after some action, for example did you just update a runtime, or do an in-app update?

[freeelectron618]

No, no changes, I've downloaded a new LLM som days ago, now I wanted to try it out, but it does not run.

[yagil]

No, no changes, I've downloaded a new LLM som days ago, now I wanted to try it out, but it does not run.

Interesting. Do you have multiple users on your Mac? Might be better to open a new issue to not spam the people on this one

[freeelectron618]

No, just me.

I deleted all extensions, and now the install in 'runtimes' worked.

[uomopalese]

Hi, I made all of the above, but download models not working anymore.

[ink-splatters]

@miranda Moving your entire home directory to another drive is absolutely an unusual configuration change. What "a lot of people do" in actuality, if they are short on boot drive space, is leave their home directory on their internal drive, and then softlink (or alias, whatever) some stuff from inside their home directory to other drives, because otherwise, booting is literally impossible without that external drive, and that's not a good configuration! What happens if that drive is misplaced, you now have a bricked laptop! No good.

Except Apple supports relocating your home directory, it is configurable that way in the accounts settings in MacOS.

So, I do not agree with this. Sure more people don't do it this way, but it is supported by Apple, and software should not fail from having a setup this way. I have never encountered anything else that doesn't work.

Of course you do not want to do this with a drive that is not always available. But it is the best way to do it if you have a thunderbolt drive that is always connected.

This problem is a bug, and it should be fixed... not ignored just because most people don't set up their system like that.

And this is why resolving ~/ early is d̶e̶f̶i̶n̶i̶t̶e̶l̶y̶ ̶n̶o̶t̶ ̶a̶ ̶g̶o̶o̶d̶ ̶p̶r̶a̶c̶t̶i̶c̶e̶ not idiomatic in general, but on macOS it's more than non-idiomatic, you just should NOT resolve ~/ early, because Apple said so (I think it's an ugly macOS feature however).

I personally hacked a `launchd` daemon which decrypts and mounts¹ home to `/Users/username`

It might be trivial, bash script-based launchd plist, but it gets more interesting if you wish to share your home across macOS installs.

Then you need to have per-system ~/Library which you mount from per-system volume, but you cannot guarantee order in which launchd loads your config unless you explicitly request an XPC service via API.

That is, you either put your small XPC service in place, or maybe hack an ugly script which mounts two things at once.

In any case, IMO it's more idiomatic than symlinking stuff

---

Off-topic but I don't feel like opening an issue for that:

it was much more painful to realize that LM-Studio now wants to live in /Applications and that this is not negotiable.

Guys, /Applications cannot be a mount point in stock macOS setup, unless you would severely hack it².

This killed my nix setup for LM-Studio. With nix you only are able to symlink it somewhere (my was symlinked to /Applications/nix/LM Studio.app, alternatively, and AFAIK that's what home manager does, ~/Applications based symlink can be used).

That's a severe degrade in UX :(

---

¹ for details, see e.g. how nix installer does that on macOS

² by which I mean going really deep.

At minimum, you will need to edit APFS metadata not exposed via APIs which you can easily google, which implies likely - manual edits via dd / hex editor or employing some Linux APFS code; in order to remove com.apple.fs.firmlink private xattr from /Application entry at system volume.

macOS loads from immutable, sealed APFS snapshot which you will need to recreate. With bless, however, only unsealed snapshot can be created, implied system protections will be disabled.

In theory it might be possible to further hack the system and trick it into loading from manually sealed, unsigned snapshot and _maybe_ preserve some protections and therefore some guarantees, but I'm not sure if it's practically achievable.

You would need to create and seal the system snapshot not simply via user-facing bless, but using another undocumented CLI apfs_sealvolume.

You can calculate merkle hash using the same tool and create img4, but it needs to be SEP-signed which I could not verify if anyone has ever hacked into.

Therefore to make it workable, you would need a custom iBoot based off of unencrypted macOS VM iBoot, which would emulate whole or most of SEP calls which you would need to reverse beforehand.

Finally you cannot have a custom iBoot without some intermediate layer like home-baked monster based on `m1n1 hypervisor from Asahi Linux guys.

[pmarreck]

@miranda Moving your entire home directory to another drive is absolutely an unusual configuration change. What "a lot of people do" in actuality, if they are short on boot drive space, is leave their home directory on their internal drive, and then softlink (or alias, whatever) some stuff from inside their home directory to other drives, because otherwise, booting is literally impossible without that external drive, and that's not a good configuration! What happens if that drive is misplaced, you now have a bricked laptop! No good.

Except Apple supports relocating your home directory, it is configurable that way in the accounts settings in MacOS.

So, I do not agree with this. Sure more people don't do it this way, but it is supported by Apple, and software should not fail from having a setup this way. I have never encountered anything else that doesn't work.

Of course you do not want to do this with a drive that is not always available. But it is the best way to do it if you have a thunderbolt drive that is always connected.

This problem is a bug, and it should be fixed... not ignored just because most people don't set up their system like that.

Well, I presented your case and my answer to ChatGPT and this is what it said 🤷‍♂ :

Yes, macOS does allow you to move your home directory to another drive, but that doesn’t make it a good idea.

You can change the home directory location in System Settings → Users & Groups → Right-click on user → Advanced Options, where you’ll find an option to set the home directory to another volume. However, this is mainly intended for cases like networked home directories (e.g., in corporate or educational environments with networked storage), not for moving a user’s only home directory to an external drive.

Why It’s a Bad Idea:

1. Boot Dependency on an External Drive – If the drive is removed, macOS won’t be able to load your profile properly, possibly preventing login or breaking applications.
2. Permissions & Ownership Headaches – macOS expects certain directories (~/Library, ~/Documents, etc.) to have specific permissions. Moving your home directory to an external drive (especially one formatted with a non-APFS filesystem) can cause permission issues.
3. Breaks System Integrity Protections – macOS integrates home directories with system services. Relocating it may cause instability with iCloud, keychain, and app sandboxing.
4. Disk Mounting Race Condition – The external drive needs to be mounted before macOS tries to access the home directory, which is unreliable and can cause boot issues.

What People Actually Do:

As you originally said, most people symlink large data directories (e.g., ~/Documents, ~/Music, ~/Movies) to an external or secondary drive. This maintains boot integrity while freeing up space.

Conclusion:

@miranda is technically correct, but this is a classic case of “Just because you can, doesn’t mean you should.” Moving an entire home directory to a removable drive is an edge-case setup, not a common or recommended practice for everyday users.

Me: And certainly not a "bug", due to what others have said about when ~/$HOME gets resolved in the boot and mounting process. If there's a high chance that (despite Apple's recommendations) 10+ common apps will make assumptions about where $HOME is located, then you can either accept reality, or start filing bugs with everyone. Good luck with that.