[Ubuntu] Ubuntu CursorやLM Studioが動かない? ⇢ AppArmorが原因

2025/09/10

(2026/02/03 更新)

UbuntuでCursorやLM Studioが動かないときの対処方法です。

結論から言うと

Ubuntu 24.04 LTS以降でCursorやLM Studioなどのアプリが動かなかったら、/etc/apparmor.d配下にプロファイルを作ると解決できるようです。例えば、LM Studioの場合:

# ダウンロードしたLM-Studio-*.AppImageを
# ~/.local/bin/LM-Studio.AppImageにファイルコピーする

# AppImageファイルに実行権を付けること
chmod +x ~/.local/bin/LM-Studio.AppImage

# AppArmorのプロファイルを作成する
sudo nano /etc/apparmor.d/lmstudio-rootless

# This profile allows everything and only exists to give the
# application a name instead of having the label "unconfined"

abi <abi/4.0>,
include <tunables/global>

profile lmstudio-rootless @{HOME}.local/bin/LM-Studio.AppImage flags=(unconfined) {
  userns,

  # Site-specific additions and overrides. See local/README for details.
  include if exists <local/lmstudio-rootless>
}

sudo systemctl reload apparmor.service

UbuntuでCursorやLM Studioで動かすとエラーが起きるのは何故か

CursorやLM StudioなどのアプリをUbuntuにダウンロードしてchmod +x (あるいはchmod a+x)で実行権を付与しただけでは、以下のようなエラーが発生して動きませんでした。

--no-sandboxオプションを付ければ起動するのですが、Cursorはアップデートをインストールする際に--no-sandboxなしで再起動しようとして上記のエラーが起こります。

対処方法は上述のとおり/etc/apparmor.dの下にAppArmorのプロファイルを作成するとよいということが分かりましたが、そもそもどういう理由でCursorやLM Studioが動かないのかを調べてみました。

CursorやLM StudioはElectronで作られている

表面的にはどちらもAppImage形式なのでこれが原因かな?と思っていたのですが、そうではなく、どちらもElectronというフレームワークで作られていることが原因でした。以下はChatGPTからの回答です:

Electronは内部でChromiumを利用しており、サンドボックス（ブラウザタブやレンダラープロセスの分離）にuser namespaceを使います。

したがって、Electron アプリ（Cursor, LM Studio など）はrestricted unprivileged user namespacesを許可するAppArmorプロファイルがないと正常に動作できないケースが出てきます。

AppArmorは非特権ユーザー名前空間 (unprivileged usernamespace)を制限する

restricted unprivileged user namespacesはUbuntu 23.10で導入され、Ubuntu 24.04からデフォルトで有効になっています。以下のコマンドの結果が1の場合は有効、0の場合は無効です。私が使っている24.04.3 LTS (Noble Numbat)では1が返ってきました。

sudo cat /proc/sys/kernel/apparmor_restrict_unprivileged_userns

この制限が導入された理由は https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction に説明されています。

ChatGPTの要約は以下のとおり。一言でまとめると「非特権ユーザー名前空間は便利だが、カーネル全体を共有しているために脆弱性があれば即システム全体に影響する構造的リスクがある」という問題を提起しています。

非特権ユーザー名前空間（unprivileged user namespaces）は、従来必要だった setuid / setgid プロセスを減らせるという利点がある一方、実装上の構造が「fail-open（制御が甘く開いてしまう）」になっているため、セキュリティ上の問題を抱えています。

第一の問題点: 非特権ユーザー名前空間でアクセスできるカーネルのインターフェースは固定されておらず、カーネルが進化するにつれて利用可能なインターフェースが増減してしまう。つまり、制御が不安定で予測不能。
第二の問題点: もしバグが悪用されると、その名前空間内だけでなく「システム全体」にアクセスされる危険がある。

背景として、ホストと非特権ユーザー名前空間は同じカーネルを共有しており、そのセキュリティは基本的に Linux capabilities（POSIX capabilities を拡張したもの）に依存している。カーネルはファイルやシステムコールなど様々なインターフェースでこの capability チェックを利用してアクセスを制御しているが、user namespace内ではこのモデルが十分に安全とは言えない。

非特権ユーザー名前空間の制限はAppArmorによるものです。したがって、AppArmorを制御することでシステム全体またはアプリごとに非特権ユーザー名前空間の許可を与えればCursorやLM Studioが動作するようになります。

アプリごとに許可を与える場合・・・冒頭のようなプロファイルを作成する
システム全体に許可を与える場合・・・以下のコマンドを実行して、非特権ユーザー名前空間の制限を無効にする

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

なお、システム全体に非特権ユーザー名前空間の制限を有効に戻すときは以下のコマンドを実行します。

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=1

AppArmorのプロファイルの構文はmanコマンドで確認できる

最後に蛇足ですが、/etc/apparmor.d配下のプロファイルの構文はmanコマンドで調べることができます。/etc/apparmor.d配下には既にchromeなどのプロファイルがあるので、それをコピーしてCursorやLM Studioなどのプロファイルを作るほうが間違いないと思います。

man apparmor.d