Obsidian AppImage가 libfuse.so.2를 찾을 때 FUSE 없이 열기

Obsidian AppImage는 릴리스 파일 검사를 통과했는데도 libfuse.so.2를 열지 못해 기동이 멈췄고, 같은 환경에 libfuse3.so.3이 있어도 오류는 그대로였습니다. 업무용 Linux 환경에 들이려면 FUSE 없이도 창을 띄울 수 있어야 해서, Debian 13에서 이 실행 오류를 재현 스크립트로 다시 만들고 해결 스크립트로 FUSE 없이 띄우는 방법을 차례로 실행했습니다. 서버에서 받아 온 실행 파일을 데스크톱 작업 환경으로 옮길 때는 파일이 온전한가와 실행에 필요한 의존성이 갖춰졌는가를 따로 봐야 합니다. 이번이 딱 그런 경우였습니다.

복구는 두 갈래로 비교했습니다. --appimage-extract로 내용을 풀어 남겨 두고 실행하는 방식, 그리고 --appimage-extract-and-run으로 그때그때 임시로 푸는 방식입니다. 쓴 파일은 릴리스 API에 나온 x86_64 AppImage와 SHA-256이 같습니다. 볼트 폴더를 인자로 넘긴 다음에는 로그에서 경로를 받았다는 줄, 창이 만들어졌다는 근거, 볼트 설정 디렉터리가 생겼는지를 하나씩 따로 읽었습니다. 프로세스가 시작됐다는 신호와 사용자가 바로 작업할 수 있다는 신호는 같은 것이 아니기 때문입니다.

비교 환경은 아래 표에 있습니다. 실행일은 실행 로그의 date -Iseconds에 찍힌 2026-10-14이고, 시각은 돌릴 때마다 달라지니 로그를 기준으로 봐 주십시오. CPU는 nproc 출력 8, 메모리는 전체 15Gi입니다. 실행 조건을 밝혀 두는 값일 뿐, Obsidian의 최소 사양을 뜻하지는 않습니다.

본문에 거는 링크는 curl -sI의 http_status가 200인 주소입니다. 릴리스 목록은 obsidianmd/obsidian-releases이고, 이번 태그의 페이지는 v1.14.4입니다. 자산 크기와 다이제스트는 최신 릴리스 API로 읽었습니다. FUSE 설명은 AppImage FUSE 트러블슈팅과 AppImageKit FUSE 위키입니다. 도움말 입구는 설치, 시작, 볼트, 링크, 태그이며 상태 코드는 모두 200입니다. 다운로드 주소의 http_status는 302라서 그 주소는 링크로 걸지 않습니다.

--version부터 막히는 AppImage와 libfuse.so.2

x86_64 파일은 이 박스의 /tmp/Obsidian.AppImage를 work에 심볼릭 링크로 두고 검사했습니다. 최신 릴리스 API의 tag_name은 v1.14.4이고 release_name은 1.14.4입니다. AppImage 자산은 두 개입니다. Obsidian-1.14.4-arm64.AppImage의 asset_size는 139902973이고, Obsidian-1.14.4.AppImage의 asset_size는 138733701입니다. uname -m이 x86_64이므로 이름에 arm64가 없는 자산을 골랐습니다. 로컬 파일의 local_size는 138733701이라 size_match는 1입니다. local_sha256는 6362ddbeeeebb7bbccb48fae009572cf2284ef92f5c919c1332aba48de6ffeaa이고, 같은 자산의 asset_digest인 sha256:6362ddbeeeebb7bbccb48fae009572cf2284ef92f5c919c1332aba48de6ffeaa와 같아 sha256_match는 1입니다.

라이브러리 목록과 직접 실행 결과를 같은 환경에서 나란히 봅니다. ls는 libfuse.so.2가 없다는 메시지와 함께, 실제로 있는 libfuse3.so.3을 보여 줍니다. 그다음 명령들은 앱 실행과 AppImage 런타임 정보 조회를 일부러 갈라 놓은 것입니다. 둘의 성공 여부를 같은 잣대로 읽으면 원인이 가려집니다.

ls -l /lib/x86_64-linux-gnu/libfuse.so.2 /lib/x86_64-linux-gnu/libfuse3.so.3
ln -sfn /tmp/Obsidian.AppImage Obsidian.AppImage
./Obsidian.AppImage --version
./Obsidian.AppImage --appimage-version
./Obsidian.AppImage --appimage-offset

로컬 파일의 크기와 다이제스트는 릴리스 자산과 맞는데, 직접 실행의 direct_exit는 1입니다. 반대로 런타임 버전과 오프셋 조회는 종료 값 0으로 끝납니다. 다운로드가 멀쩡해도 앱을 띄우는 단계에서 의존성 오류가 날 수 있다는 것을 이 대비가 그대로 보여 줍니다.

+ . /etc/os-release
PRETTY_NAME=Debian GNU/Linux 13 (trixie)
VERSION=13 (trixie)
VERSION_ID=13
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.7
+ uname -s
Linux
+ uname -m
x86_64
+ python3 --version
Python 3.13.5
+ curl --version
curl 8.14.1 (x86_64-pc-linux-gnu) libcurl/8.14.1 OpenSSL/3.5.7 zlib/1.3.1 brotli/1.1.0 zstd/1.5.7 libidn2/2.3.8 libpsl/0.21.2 libssh2/1.11.1 nghttp2/1.64.0 nghttp3/1.8.0 librtmp/2.3 OpenLDAP/2.6.10
+ printf LANG
LANG=C.UTF-8
+ date -Iseconds
2026-10-14T15:44:49+09:00
+ nproc
8
+ free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi        11Gi       1.1Gi       168Mi       3.6Gi       4.2Gi
Swap:             0B          0B          0B
+ ls /lib/x86_64-linux-gnu/libfuse.so.2 /lib/x86_64-linux-gnu/libfuse3.so.3
ls: cannot access '/lib/x86_64-linux-gnu/libfuse.so.2': No such file or directory
-rw-r--r-- 1 root root 264216 Oct 14 14:25 /lib/x86_64-linux-gnu/libfuse3.so.3
+ ln -sfn /tmp/Obsidian.AppImage Obsidian.AppImage
lrwxrwxrwx 1 box box 22 Oct 14 15:44 Obsidian.AppImage -> /tmp/Obsidian.AppImage
+ curl -sI official urls
http_status=200 url=https://github.com/obsidianmd/obsidian-releases
http_status=200 url=https://github.com/obsidianmd/obsidian-releases/releases/tag/v1.14.4
http_status=302 url=https://github.com/obsidianmd/obsidian-releases/releases/download/v1.14.4/Obsidian-1.14.4.AppImage
http_status=200 url=https://api.github.com/repos/obsidianmd/obsidian-releases/releases/latest
http_status=200 url=https://docs.appimage.org/user-guide/troubleshooting/fuse.html
http_status=200 url=https://github.com/AppImage/AppImageKit/wiki/FUSE
http_status=200 url=https://obsidian.md/help/install
http_status=200 url=https://obsidian.md/help/getting-started
http_status=200 url=https://obsidian.md/help/vault
http_status=200 url=https://obsidian.md/help/links
http_status=200 url=https://obsidian.md/help/tags
+ python3 release metadata and sha256
tag_name=v1.14.4
published_at=2026-10-05T17:03:28Z
release_name=1.14.4
asset_name=Obsidian-1.14.4-arm64.AppImage
asset_size=139902973
asset_digest=sha256:721829a4f0ffadf7674f396aed58a5699e116b76b78747873d1751193efb66a9
asset_name=Obsidian-1.14.4.AppImage
asset_size=138733701
asset_digest=sha256:6362ddbeeeebb7bbccb48fae009572cf2284ef92f5c919c1332aba48de6ffeaa
local_size=138733701
local_sha256=6362ddbeeeebb7bbccb48fae009572cf2284ef92f5c919c1332aba48de6ffeaa
size_match=1
sha256_match=1
+ ./Obsidian.AppImage --version
dlopen(): error loading libfuse.so.2

AppImages require FUSE to run. 
You might still be able to extract the contents of this AppImage 
if you run it with the --appimage-extract option. 
See https://github.com/AppImage/AppImageKit/wiki/FUSE 
for more information
direct_exit=1
+ ./Obsidian.AppImage --appimage-version
Version: effcebc
runtime_exit=0
+ ./Obsidian.AppImage --appimage-offset
188392
offset_exit=0

터미널 캡처를 보면 무결성 검사를 통과한 파일이 라이브러리를 불러오다 멈춥니다. 앱 직접 실행은 종료 값 1을 남겼고, 런타임 정보 조회는 성공했습니다. 장애 기록에 마지막으로 성공한 명령만 남겨 두면 이 흐름이 사라집니다. 실패한 실행과 바로 앞의 환경 정보를 같이 보관해야 나중에 원인을 되짚을 수 있습니다.

런타임은 살아 있는데 앱 실행만 FUSE에 걸리는 이유

./Obsidian.AppImage --version의 첫 줄은 dlopen(): error loading libfuse.so.2입니다. 이어서 AppImages require FUSE to run.이 나오고, --appimage-extract로 내용을 풀 수 있다는 안내와 https://github.com/AppImage/AppImageKit/wiki/FUSE 주소가 나옵니다. 이 명령의 direct_exit는 1입니다. 앱 버전 문자열이 없으므로 이 종료 코드만으로는 설치 성공으로 판단할 수 없습니다.

ls는 libfuse.so.2에 대해 No such file or directory를 찍고, /lib/x86_64-linux-gnu/libfuse3.so.3은 일반 파일로 나옵니다. FUSE 3 파일이 있어도 런타임이 요청한 파일 이름 libfuse.so.2는 충족되지 않습니다. AppImageKit FUSE 위키에서 찾은 문장은 Some AppImages require FUSE version 2 to run.입니다.

페이로드를 열기 전 런타임은 동작합니다. --appimage-version은 Version: effcebc를 찍고 runtime_exit는 0입니다. --appimage-offset은 188392를 찍고 offset_exit는 0입니다. 바깥 런타임이 파일 오프셋을 읽는 단계와, libfuse.so.2를 불러 앱을 띄우는 단계는 나뉩니다.

--appimage-extract로 풀어서 바이너리를 직접 실행하기

FUSE 없이 창을 띄우는 첫 방법은 AppImage를 작업 디렉터리의 squashfs-root로 푼 다음, 그 안의 obsidian 바이너리를 --no-sandbox와 작업 폴더 안의 --user-data-dir로 실행하는 것입니다. HOME과 XDG_CONFIG_HOME, XDG_CACHE_HOME, XDG_DATA_HOME, TMPDIR도 work 아래로 두었습니다. 볼트용으로 마크다운 두 개가 있는 폴더를 만들어 인자로 넘겼습니다.

./Obsidian.AppImage --appimage-extract
grep -E '^(Name|Exec|X-AppImage-Version)=' squashfs-root/md.obsidian.Obsidian.desktop
./squashfs-root/obsidian --no-sandbox --user-data-dir="$DATA" "$VAULT" > "$LOG" 2>&1 &

추출 결과에서는 실행 파일이 있는지와 앱이 실제로 뜨는지를 함께 확인합니다. 출력의 343M는 디스크에 남은 추출 트리의 크기이고 메모리 사용량이 아닙니다. --no-sandbox는 이번 실행에도, 데스크톱 항목에도 들어 있는 옵션이라 기동 기록을 다시 만들 때는 이 옵션과 사용자 데이터 경로를 같이 맞춰야 합니다.

+ ln -sfn /tmp/Obsidian.AppImage Obsidian.AppImage
+ ./Obsidian.AppImage --appimage-extract
squashfs-root/.DirIcon
squashfs-root/AppRun
squashfs-root/LICENSE.electron.txt
squashfs-root/LICENSES.chromium.html
squashfs-root/chrome-sandbox
squashfs-root/chrome_100_percent.pak
squashfs-root/chrome_200_percent.pak
squashfs-root/chrome_crashpad_handler
squashfs-root/icudtl.dat
squashfs-root/libEGL.so
squashfs-root/libGLESv2.so
squashfs-root/libffmpeg.so
squashfs-root/libvk_swiftshader.so
squashfs-root/libvulkan.so.1
squashfs-root/locales
squashfs-root/locales/af.pak
squashfs-root/locales/am.pak
squashfs-root/locales/ar.pak
squashfs-root/locales/bg.pak
squashfs-root/locales/bn.pak
squashfs-root/locales/ca.pak
squashfs-root/locales/cs.pak
squashfs-root/locales/da.pak
squashfs-root/locales/de.pak
squashfs-root/locales/el.pak
squashfs-root/locales/en-GB.pak
squashfs-root/locales/en-US.pak
squashfs-root/locales/es-419.pak
squashfs-root/locales/es.pak
squashfs-root/locales/et.pak
squashfs-root/locales/fa.pak
squashfs-root/locales/fi.pak
squashfs-root/locales/fil.pak
squashfs-root/locales/fr.pak
squashfs-root/locales/gu.pak
squashfs-root/locales/he.pak
squashfs-root/locales/hi.pak
squashfs-root/locales/hr.pak
squashfs-root/locales/hu.pak
squashfs-root/locales/id.pak
squashfs-root/locales/it.pak
squashfs-root/locales/ja.pak
squashfs-root/locales/kn.pak
squashfs-root/locales/ko.pak
squashfs-root/locales/lt.pak
squashfs-root/locales/lv.pak
squashfs-root/locales/ml.pak
squashfs-root/locales/mr.pak
squashfs-root/locales/ms.pak
squashfs-root/locales/nb.pak
squashfs-root/locales/nl.pak
squashfs-root/locales/pl.pak
squashfs-root/locales/pt-BR.pak
squashfs-root/locales/pt-PT.pak
squashfs-root/locales/ro.pak
squashfs-root/locales/ru.pak
squashfs-root/locales/sk.pak
squashfs-root/locales/sl.pak
squashfs-root/locales/sr.pak
squashfs-root/locales/sv.pak
squashfs-root/locales/sw.pak
squashfs-root/locales/ta.pak
squashfs-root/locales/te.pak
squashfs-root/locales/th.pak
squashfs-root/locales/tr.pak
squashfs-root/locales/uk.pak
squashfs-root/locales/ur.pak
squashfs-root/locales/vi.pak
squashfs-root/locales/zh-CN.pak
squashfs-root/locales/zh-TW.pak
squashfs-root/md.obsidian.Obsidian.desktop
squashfs-root/obsidian
squashfs-root/obsidian-cli
squashfs-root/obsidian.png
squashfs-root/resources
squashfs-root/resources/app.asar
squashfs-root/resources/app.asar.unpacked
squashfs-root/resources/app.asar.unpacked/node_modules
squashfs-root/resources/app.asar.unpacked/node_modules/btime
squashfs-root/resources/app.asar.unpacked/node_modules/btime/binding.node
squashfs-root/resources/app.asar.unpacked/node_modules/btime/index.js
squashfs-root/resources/app.asar.unpacked/node_modules/btime/package.json
squashfs-root/resources/app.asar.unpacked/node_modules/get-fonts
squashfs-root/resources/app.asar.unpacked/node_modules/get-fonts/binding.node
squashfs-root/resources/app.asar.unpacked/node_modules/get-fonts/fontsMac.mm
squashfs-root/resources/app.asar.unpacked/node_modules/get-fonts/index.js
squashfs-root/resources/app.asar.unpacked/node_modules/get-fonts/package.json
squashfs-root/resources/icon.png
squashfs-root/resources/obsidian.asar
squashfs-root/resources.pak
squashfs-root/snapshot_blob.bin
squashfs-root/usr
squashfs-root/usr/lib
squashfs-root/usr/lib/libXss.so.1
squashfs-root/usr/lib/libXtst.so.6
squashfs-root/usr/lib/libappindicator.so.1
squashfs-root/usr/lib/libgconf-2.so.4
squashfs-root/usr/lib/libindicator.so.7
squashfs-root/usr/lib/libnotify.so.4
squashfs-root/usr/share
squashfs-root/usr/share/icons
squashfs-root/usr/share/icons/hicolor
squashfs-root/usr/share/icons/hicolor/128x128
squashfs-root/usr/share/icons/hicolor/128x128/apps
squashfs-root/usr/share/icons/hicolor/128x128/apps/obsidian.png
squashfs-root/usr/share/icons/hicolor/16x16
squashfs-root/usr/share/icons/hicolor/16x16/apps
squashfs-root/usr/share/icons/hicolor/16x16/apps/obsidian.png
squashfs-root/usr/share/icons/hicolor/24x24
squashfs-root/usr/share/icons/hicolor/24x24/apps
squashfs-root/usr/share/icons/hicolor/24x24/apps/obsidian.png
squashfs-root/usr/share/icons/hicolor/256x256
squashfs-root/usr/share/icons/hicolor/256x256/apps
squashfs-root/usr/share/icons/hicolor/256x256/apps/obsidian.png
squashfs-root/usr/share/icons/hicolor/32x32
squashfs-root/usr/share/icons/hicolor/32x32/apps
squashfs-root/usr/share/icons/hicolor/32x32/apps/obsidian.png
squashfs-root/usr/share/icons/hicolor/48x48
squashfs-root/usr/share/icons/hicolor/48x48/apps
squashfs-root/usr/share/icons/hicolor/48x48/apps/obsidian.png
squashfs-root/usr/share/icons/hicolor/512x512
squashfs-root/usr/share/icons/hicolor/512x512/apps
squashfs-root/usr/share/icons/hicolor/512x512/apps/obsidian.png
squashfs-root/usr/share/icons/hicolor/64x64
squashfs-root/usr/share/icons/hicolor/64x64/apps
squashfs-root/usr/share/icons/hicolor/64x64/apps/obsidian.png
squashfs-root/usr/share/mime
squashfs-root/usr/share/mime/packages
squashfs-root/usr/share/mime/packages/obsidian.xml
squashfs-root/v8_context_snapshot.bin
squashfs-root/vk_swiftshader_icd.json
+ du -sh squashfs-root
343M	squashfs-root
+ grep desktop entry
Name=Obsidian
Exec=AppRun --no-sandbox %U
X-AppImage-Version=1.14.4
+ test -x squashfs-root/obsidian squashfs-root/AppRun
obsidian_executable=1
apprun_executable=1
+ create vault markdown
+ find vault
/home/user/obsidian/run/work/vault
/home/user/obsidian/run/work/vault/두 번째 노트.md
/home/user/obsidian/run/work/vault/첫 노트.md
+ grep wikilink and tag
/home/user/obsidian/run/work/vault/첫 노트.md:2:[[두 번째 노트]]를 적는다. #입문
DISPLAY=:6
+ ./squashfs-root/obsidian --no-sandbox --user-data-dir="$DATA" "$VAULT"
launch_ready=1
+ filtered launch log
2026-10-14 06:45:13 Loaded main app package /home/user/obsidian/run/work/squashfs-root/resources/obsidian.asar
Received file path /home/user/obsidian/run/work/vault
2026-10-14 06:45:14 Checking for update using Github
2026-10-14 06:45:14 Success.
2026-10-14 06:45:14 Latest version is 1.14.4
2026-10-14 06:45:14 App is up to date.
+ xwininfo
     0x2200001 "obsidian": ("obsidian" "Obsidian")  10x10+10+10  +10+10
        0x2000004 "Obsidian": ("md.obsidian.obsidian" "md.obsidian.Obsidian")  800x650+0+0  +560+275
+ xdotool getwindowname
obsidian
Obsidian
+ find vault after launch
/home/user/obsidian/run/work/vault
/home/user/obsidian/run/work/vault/두 번째 노트.md
/home/user/obsidian/run/work/vault/첫 노트.md
vault_obsidian_dir=0
solution_ok=1
+ stop obsidian
stopped=1

수동 추출 후 실행한 캡처에는 창 목록과 solution_ok=1이 찍혀 있습니다. 로그에 넘긴 볼트 경로가 나오고 창 조회에도 Obsidian이 잡힙니다. 그런데 같은 출력의 vault_obsidian_dir=0을 놓치면 창이 뜬 것을 볼트가 등록된 것으로 착각하게 됩니다.

캡처에는 볼트 위치가 긴 작업 폴더 경로로 나오지만, 본문 코드블록은 앞부분을 /home/user/obsidian으로 줄였을 뿐 같은 실행에서 나온 같은 로그입니다.

du -sh squashfs-root는 343M입니다. 데스크톱 항목은 Name=Obsidian, Exec=AppRun --no-sandbox %U, X-AppImage-Version=1.14.4입니다. obsidian_executable과 apprun_executable은 둘 다 1입니다. 이번 기동에 쓴 파일은 데스크톱 항목이 가리키는 AppRun이 아니라 squashfs-root/obsidian입니다.

필터한 로그에는 Loaded main app package 다음에 Received file path와 볼트 폴더 경로가 있습니다. 이어서 Checking for update using Github, Success., Latest version is 1.14.4, App is up to date.가 나옵니다. launch_ready는 1이고 solution_ok는 1입니다.

xwininfo에는 클래스 md.obsidian.Obsidian인 창 이름 Obsidian과 기하 정보가 있습니다. 명령이 반환됐다는 사실에 더해 실제 창이 만들어졌다는 근거로 읽을 수 있습니다. xdotool이 찍은 이름도 obsidian과 Obsidian입니다.

이 방식은 패키지를 하나도 설치하지 않고 바이너리를 띄우고, squashfs-root가 남아 있으니 다음 실행에서 다시 풀 필요도 없습니다. 그 대가로 작업 디렉터리에 343M가 남습니다. AppImage 공식 문서도 압축을 풀어 실행하는 데 드는 비용을 따로 설명합니다.

extract-and-run 임시 실행과 볼트 인자를 따로 확인하기

AppImage 공식 문서는 --appimage-extract-and-run도 안내합니다. 이번 스크립트는 그 인자에 --no-sandbox와 별도의 --user-data-dir를 붙이고, TMPDIR을 work/ear-tmp로 두어 임시 풀기가 이 폴더 안에서 일어나게 했습니다. 수동으로 푼 트리와 사용자 데이터 디렉터리는 겹치지 않습니다.

./Obsidian.AppImage --appimage-extract-and-run --no-sandbox --user-data-dir="$DATA" "$VAULT" > "$LOG" 2>&1 &

문서에서 뽑은 대체 실행 안내와 실제 자동 추출 실행 결과가 한 출력에 들어 있습니다. 실행 중에는 임시 디렉터리가 1개였고, 끝난 뒤에는 0개로 기록됐습니다. 수동 추출 때와 같은 버전 로그가 나오는지 보면서, 임시 파일이 언제까지 살아 있는지도 비교할 수 있습니다.

+ ln -sfn /tmp/Obsidian.AppImage Obsidian.AppImage
+ curl -fsSL fuse documents
+ python3 print documented fallback lines
doc_has=1 text=AppImages require FUSE to run.
doc_has=1 text=./my.AppImage --appimage-extract-and-run
doc_has=1 text=export APPIMAGE_EXTRACT_AND_RUN=1
doc_has=1 text=./my.AppImage --appimage-extract
doc_has=1 text=squashfs-root/AppRun
doc_has=1 text=Extracting an AppImage to run its contents is pretty expensive.
doc_has=1 text=sudo apt install libfuse2
wiki_has=1 text=Debian (>= 13)
wiki_has=1 text=sudo apt install libfuse2t64
wiki_has=1 text=Some AppImages require FUSE version 2 to run.
wiki_has=1 text=--appimage-extract
package_has=1 text=Open folder as vault
package_has=1 text=Choose an existing folder of Markdown files.
package_has=1 text=Create new vault
package_has=1 text=Create a new Obsidian vault under a folder.
DISPLAY=:6
+ ./Obsidian.AppImage --appimage-extract-and-run --no-sandbox --user-data-dir="$DATA" "$VAULT"
extract_and_run_ready=1
extracted_dirs_while_running=1
+ filtered extract-and-run log
Received file path /home/user/obsidian/run/work/vault
2026-10-14 06:45:26 Latest version is 1.14.4
2026-10-14 06:45:26 App is up to date.
+ locate extracted dir
+ stop extract-and-run child and wait for parent
extracted_dirs_after=0
alt_ok=1

자동 추출 방식의 캡처에는 기동과 종료 후 정리 결과가 함께 있습니다. alt_ok=1과 extracted_dirs_after=0이 남았으니 이번 실행에서는 임시 추출물이 종료와 함께 치워졌습니다. 어떤 실행 경로를 기본으로 삼을지는 이 정리 결과와, 열 때마다 다시 풀어야 하는 비용을 같이 놓고 정합니다.

필터한 로그는 다시 Received file path, Latest version is 1.14.4, App is up to date.입니다. extract_and_run_ready는 1이고 alt_ok는 1입니다. 앱이 떠 있는 동안 extracted_dirs_while_running은 1이었습니다. 자식 프로세스를 끝내고 부모가 빠진 뒤 extracted_dirs_after는 0입니다. 이번 실행에서는 임시 디렉터리가 실행 중에만 있었고, 끝난 뒤의 개수는 0입니다.

인자 하나로 풀기와 실행이 이어지고, 이번에는 끝난 뒤 임시 디렉터리 수가 0이었다는 점이 자동 추출의 장점입니다. 버전 로그도 수동 풀기와 똑같습니다. 다만 실행할 때마다 다시 풀어야 하고, 같은 공식 문서가 그 비용을 설명합니다. 반복해서 연다면 남겨 둔 squashfs-root 쪽이 낫습니다.

볼트 인자도 창이 떴다는 사실과 분리해서 읽어야 합니다. find는 work/vault 아래 마크다운 두 개의 경로를 찍었고, grep은 첫 노트.md 2행에서 [[두 번째 노트]]를 적는다. #입문을 찍었습니다. 실행이 끝난 뒤 같은 폴더를 다시 find해도 .obsidian은 없고 vault_obsidian_dir는 0입니다. 로그의 Received file path는 그 경로를 받았다는 줄이지, 볼트 설정 디렉터리가 생겼다는 줄은 아닙니다.

추출 실행으로 바꾼 뒤 점검 대상도 옮기기

출력에 모인 문서 안내부터 패키지 이름이 서로 다릅니다. AppImage 문서에는 sudo apt install libfuse2가 있고, 위키의 Debian (>= 13) 항목에는 sudo apt install libfuse2t64가 나옵니다. 기존 설치 절차를 그대로 옮겨 오면 안 되고, 배포판에 맞는 패키지 안내로 바꿔 둬야 합니다. 이 기록에서 실제로 기동에 성공한 경로는 추출 실행입니다. 패키지 설치 쪽을 택한다면, 설치한 뒤 직접 실행이 정말 되는지 다시 확인하는 절차를 붙여야 합니다.

헬스체크도 AppImage 런타임이 응답한다는 것만으로 끝내면 곤란합니다. 이번에도 --appimage-version은 성공했지만 앱 직접 실행은 실패했습니다. 실행 경로를 추출한 바이너리로 바꿨다면 점검 대상도 그 경로와 실제 창 생성으로 옮기고, 볼트 준비 여부는 따로 봅니다. 사용자 데이터는 --user-data-dir로 정한 경로, 임시 추출은 TMPDIR, 문서 파일은 볼트 경로로 나눠 두면 업데이트 뒤에 어느 설정을 봐야 할지 헷갈리지 않습니다.

남겨 두는 추출과 매번 푸는 추출, 그리고 FUSE 설치

같은 1.14.4 파일로 두 가지 해결 방법을 견줘 보면 다음과 같습니다. 표에는 실행 로그에 있는 값만 옮겼습니다.

여러 번 열 환경이라면 수동 추출을 고르겠습니다. squashfs-root가 343M로 남아 있으니 다음 실행에서 추출을 되풀이하지 않습니다. 한 번 보고 작업 디렉터리를 비울 생각이라면 --appimage-extract-and-run이 맞습니다. 이번 실행에서는 프로세스가 끝난 뒤 임시 디렉터리 수가 0이었습니다.

파일 고를 때는 이름만 보지 말고 API의 다이제스트를 맞추면 됩니다. 이번 x86_64 파일은 sha256_match=1이었고, arm64 자산은 크기 139902973과 다른 다이제스트로 같은 응답에 따로 있습니다. 이번 기동에 쓴 파일은 이름에 arm64가 없는 AppImage입니다. 런타임이 살아 있는지만 볼 때는 --appimage-version의 Version: effcebc와 --appimage-offset의 188392를 보면 됩니다. 그 두 명령은 FUSE 없이도 runtime_exit=0, offset_exit=0이었습니다.

추출 실행과 자동 추출 실행의 출력을 놓고 보면, 반복해서 여는 업무용 환경에 수동 추출한 바이너리와 고정된 사용자 데이터 경로를 함께 두는 구성을 권합니다. 추출 트리 343M를 디스크에 두는 대신 다음 기동부터 추출을 건너뛰는 선택입니다. 일회성 점검에는 자동 추출 방식이 편했고, 종료 후 임시 디렉터리가 정리되는 것도 확인했습니다. 어느 방식이든 볼트 경로를 받았다는 로그 한 줄로 작업 준비가 끝났다고 보지 말고, 실제로 쓸 폴더를 열어 설정 상태까지 봐야 합니다.

저라면 이 앱의 실행 환경을 서버의 상시 처리 역할과 떼어 두겠습니다. 이번 성공 기록에는 DISPLAY=:6과 창 조회 결과가 들어 있어서, 실시간 서비스 구성을 판단하는 근거로 그대로 가져다 쓸 수는 없습니다. 상시 작업이 필요하다면 데스크톱 앱은 편집 환경에 두고, 서비스 처리 경로는 별도로 설계하기를 권합니다. 업데이트 때마다 자산의 아키텍처와 다이제스트, 실행 경로, 사용자 데이터 위치를 함께 점검해 두면 이번 같은 의존성 문제도 복구 절차 안에서 처리됩니다.