obsproject / obsproject/obs-studio

macOS: "Failed to create required user directories" on first launch

Open
#12,702 13 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

issue/confirmed issue/workaround platform/macos
Dominant language
C
Stars
76.4k
Forks
10.2k
Avg merge
4d 23h
Merged PRs (30d)
12

Description

[!NOTE]
For those who have found this issue thread and are just looking for the fix, see this top area.

This issue is caused by Logitech, whose software creates OBS's data directory on first launch, without asking the user. It performed this directory creation as the root user, leading to an OBS data directory that OBS itself is later unable to access.

To resolve the issue, open Terminal and transfer ownership of the OBS directory to your own user account with the following command (making sure to copy-paste the command exactly):

sudo chown -R $(whoami) ~/Library/Application\ Support/obs-studio

Old issue thread below:


Operating System Info

macOS 15

OBS Studio Version

32.0.0

OBS Studio Log URL

No log is created in this failure mode. stdout is simply:

error: Failed to create required user directories
zsh: segmentation fault  /Applications/OBS.app/Contents/MacOS/OBS
OBS Studio Crash Log URL

This failure does crash OBS, but that is a separate issue (see #12617). Failure to create data directories is fundamentally unrecoverable anyway and is the focus of this issue.

Expected Behavior

OBS to launch normally on first launch post-installation, creating its data directories.

Current Behavior

Users, typically on the first launch/installation of OBS, are being met with the following error dialog and subsequent launch failure.

Image
Steps to Reproduce
  1. Unknown preconditions (the issue seems to occur on first launch/installation for some users)
  2. Attempt to launch OBS
Anything else we should know?

This is a thread to aggregate investigation of an issue being somewhat commonly reported in OBS support channels recently. It is not new to OBS 32.0, and at best guess seems to have possibly been triggered by a change in behavior on macOS somewhere in the macOS 15 release cycle, or at least some change with software that is not OBS itself. It is known to occur on both macOS 15 and macOS 26.

From investigation, this seems to occur because OBS's data directory (~/Library/Application Support/obs-studio) is owned by root (with group staff), and our attempts to create required data directories inside of it (as the non-root user) fail as a result.

It may be possible to assume that it is OBS's call to mkdir that creates the directory with this owner/group, but that would be puzzling since users hitting this issue are not running OBS as root, and there does not appear to be any code in OBS that would call mkdir on the data directory with any sort of elevated permission.

It wouldn't be out of the realm of possibility that some other program is creating OBS's data directory as root, but this would be very unusual, and we have yet to identify any commonality in the users systems that are running this issue (such as users that ran some sort of plugin installer that behaved poorly, for example, before running OBS, or launching a fork of OBS prior to OBS itself that behaved poorly).

This thread is meant to serve as a hub for investigation of why this may be happening, as well as possible resolutions (adding a workaround to destroy and recreate the directory if it's owned by root?), as well as for users to know that the project is aware of the issue.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the first-launch failure on macOS 15 or 26 and inspect the OBS data directory ownership alongside the reported stdout. The issue names no source file or test; done would mean a normal first launch even when the directory was created by another process, with a verified regression test or reproduction result.

Written by the indexing model from the issue text.

Assessment

Tech stack
macos
Domain
desktop
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.