A Linux restart does not preserve an OBS Media Source by itself. To have it load again, preserve the Scene Collection and Profile separately, keep each referenced file reachable at its configured path, and check everything under the account and runtime that actually launches OBS.
A source set to Loop can repeat a file that OBS can read; it cannot restore a missing scene, file or mount. Work through the persistence checks below before treating a playback option as a recovery fix, and test the real startup arrangement before relying on it for a YouTube broadcast.
Why media sources break after a restart
A Media Source depends on more than the play button in its properties. OBS must load the Scene Collection that contains the source, the source must still point to the intended file, and the process must be able to read that file when it starts. If a disk or network share provides the file, that mount must also be available to the process.
A restart can expose a problem that was hidden while the server was running. A manually opened OBS session may have loaded a collection that was never saved; a file may have been under a temporary directory; or the disk containing it may not yet be mounted when OBS launches. The result can look similar in the preview—a blank or absent source—but the cause differs.
Start by separating the symptoms. If the expected scenes and sources are absent, check which Scene Collection and OBS configuration the process loaded. If the source is visible in the scene but blank, inspect its configured path, file availability, permissions and format. If it plays but starts at an unexpected point, then investigate playback behaviour. This order prevents changing a playback toggle when the actual fault is that OBS cannot find the file.
OBS documents Media Source as a way to play local audio or video files on Linux. Its Media Sources guide describes playback controls, but a local file remains a dependency outside the scene definition. That distinction matters on a server because configuration can persist while the file location or the runtime account does not.
For a YouTube channel, this is a preparation and recovery problem, not a promise about broadcast continuity. A server restart may interrupt the active broadcast; do not assume OBS or YouTube will resume the same live event automatically. Confirm the stream and event behaviour using current YouTube guidance and a controlled test before you depend on it.
Save the Scene Collection and Profile separately
OBS stores different parts of the setup in different places. The Scene Collection holds scenes and their sources; the Profile holds settings such as stream destination, video and output configuration. A backup of one is not a backup of the other. OBS’s Scene Collections guide explains collection management, while its Profiles guide covers profile management and export.
While the working setup is still available, save the current Scene Collection and export it as a recovery copy. Separately export the Profile settings. Give the copies clear names that help you identify the channel and the purpose of the backup, then store them somewhere that will not disappear when the server is rebuilt or a temporary runtime is discarded. A second copy on another device or storage location is useful if the server disk itself fails.
Do not rely on an exported Profile to bring back the scene layout. After restoring or moving OBS, check that the intended collection is loaded as well as the intended Profile. A profile can contain the correct YouTube output settings while OBS opens a different collection with no media sources; conversely, the scene may be present while the output profile is not the one you expect.
A simple recovery record helps when the interface is not familiar after a reboot. Note the collection name, profile name, media file paths, and where the files are stored. If you manage more than one channel, identify which pair belongs together. Keep credentials such as a stream key out of public notes, screenshots and backups that are not protected.
These exports are recovery aids, not a substitute for checking the installed OBS version or the location used by its actual runtime. After an update, package change or account change, verify that OBS can see and load the saved configuration. The OBS Linux installation guide is a starting point for understanding the supported installation choices; it does not prescribe one universal configuration path for every distribution or packaging method.
Keep referenced files at reachable paths
A scene records where a Media Source file is expected; it does not turn the file into part of the scene. If the file is renamed, moved, stored on a removable disk that is absent, or placed in a directory that changes between sessions, the source can remain in the scene yet fail to play. Exporting configuration does not copy the media assets along with it.
For each Media Source, open its properties and record the exact file path. Check that the file exists at that path after a restart, rather than only checking that a copy exists somewhere on the server. A file in /home/channel/videos/loop.mp4, for example, is a different dependency from a similarly named file under /mnt/media/loop.mp4. The configured path needs to match the location available to the running process.
Prefer a stable directory intended for persistent media over a temporary folder, a desktop download directory, or a path tied to a short-lived session. If you must reorganise media, update the source path in OBS and test playback before considering the move complete. Preserve a copy of the original until the replacement is confirmed.
If your setup uses a disk or network share, treat its mount point and readiness as part of the media dependency. A path under /mnt/media is only useful if the storage is actually mounted there and contains the expected files when OBS tries to load them. A bare directory with the same name can exist even when the underlying storage has not mounted, which makes a quick path check misleading.
For a playlist or a devotional channel with several files, check every referenced item rather than only the first one visible in the preview. A single missing item may appear later, after the current file ends. If the broadcast uses a larger playlist, a repeatable file inventory and stable paths reduce the chance that a restart reveals a missing item hours into playback. See the practical considerations in streaming prerecorded video to YouTube from a Linux VPS when comparing an OBS workflow with a file-based alternative.
Verify mounts and permissions under the live account
The useful question is not just whether you can see the file when logged in. It is whether the OBS process used for the live channel can see and read it. A service, container, desktop login and shell started as different Linux users can have different home directories, permissions, mount namespaces and environment settings. A path that works when you open OBS manually may not work when the production process starts after reboot.
Identify the account that owns the actual OBS process and compare it with the account used during your manual test. Check read access to the media file and traverse access to every parent directory in its path. If the file is on a mount, check that this same runtime sees the mount, not only that the host has a mount point with the expected name.
Avoid solving the problem by making media directories broadly writable or readable without understanding the consequence. OBS generally needs to read the media, not rewrite it. Use permissions appropriate to the account and storage arrangement, and keep a record of deliberate ownership or access changes so they are not lost during a redeployment.
For mounted storage, establish a practical startup order: the required storage should be available before the OBS process attempts to load the source. The exact mechanism depends on the distribution, package and deployment arrangement. Do not copy a system service template from another server without checking the user, package, display or session requirements, and mount behaviour of your own installation.
If a collection opens but one source is blank, test the file path from the same account and context as OBS. If a scene itself is missing, return to the collection and configuration identity checks instead. Those two symptoms call for different fixes. A basic OBS setup for a YouTube live stream also depends on using the correct output settings, but those settings cannot make an inaccessible local file readable.
Check the OBS startup and runtime arrangement
Write down how the live OBS process is started: for example, from a logged-in desktop, a scheduled startup, a container, or a service arrangement maintained for your server. The important point is not to pick one universal method; it is to test the same method you intend to use in production. Starting a second manual instance after reboot can hide the fact that the automatic process opened a different profile or collection.
When OBS is running after a restart, confirm the account, expected Scene Collection and Profile before inspecting the source. Compare what the interface shows with your recovery record. If the collection or profile differs, resolve that identity mismatch first; otherwise you may spend time repairing a path in a configuration that the live setup never uses.
The OBS configuration location depends on how OBS was installed and which account runs it. Do not assume that a configuration copied into one user’s home directory is automatically read by a service or container. Find the configuration actually used by the production process, preserve its collection and profile, and confirm that the process continues to use them after restart.
OBS explicitly says that portable mode is not supported on Linux. Do not base a Linux-server repair on portable mode or assume that putting configuration beside the application will make the full setup self-contained. OBS also cautions that media files used by a Scene Collection are not portable simply because configuration is moved. The media paths and files still need to be available to the runtime.
When you cannot keep a desktop session or OBS process stable through server restarts, consider whether a different operating approach is a better fit. A file-based FFmpeg workflow, for example, has different configuration and recovery requirements, so it is not a drop-in repair for an OBS Scene Collection. This comparison of FFmpeg loop streams on one VPS may help you assess that alternative, but test the chosen arrangement independently.
Test playback after a controlled restart
Make the test before the next real broadcast, while you can inspect the server. First save the current collection and profile exports, then ensure the media files are at their intended paths and the required mounts are available. Restart the server and launch OBS exactly as the live arrangement will launch it. Do not substitute a convenient manual start if the channel normally relies on an automated one.
Once OBS opens, check the collection and profile names against your notes. Preview each relevant Media Source, including items that appear later in a playlist. Confirm that video is visible and audio is present at a sensible level. If a source is blank, check the configured path and read access from the live account; if the source is absent from the scene, check the loaded collection first.
A short recording can help you verify the result without starting a public broadcast. OBS’s Quick Start Guide recommends testing settings before streaming. Apply that principle to reboot testing: confirm the expected output settings and inspect a sample of the resulting audio and video. A test recording does not establish what YouTube will do after an interrupted live event, so treat broadcast reconnection as a separate question and consult current official YouTube Live guidance.
Keep the test notes factual: what started, what did not, which account ran OBS, which collection and profile loaded, and whether the mount was ready. If a test fails, change one relevant part of the arrangement and repeat it. A successful manual preview is useful, but it does not prove the next automated startup will use the same account, files or settings.
What Loop and Restart playback cannot repair
Loop controls whether a Media Source repeats its content after playback reaches the end. Restart playback when source becomes active controls playback when the source becomes visible in the current scene. Neither setting recreates a deleted Scene Collection, brings an unmounted disk online, changes a stale path, or grants the OBS process file access.
Close file when inactive is another playback and resource behaviour: it can unload media while a source is hidden and require it to load again when used. If that source then fails, investigate its file availability and runtime access rather than assuming that a different loop setting will recover it. Browser Source refresh controls concern web content and do not repair a local Media Source file path.
Use playback controls only after the underlying persistence checks pass. If the file exists at the configured path, the process can read it, and the correct collection is loaded, then choose Loop or restart behaviour according to how you want the content to play. For a continuous ambience video, repeating the file may be appropriate; for a clip that should begin at the start whenever its scene becomes active, the restart option may match the intended behaviour. These are editorial choices about playback, not reboot recovery.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Why are my OBS media sources missing after a Linux restart?
First check whether OBS loaded the expected Scene Collection, because scenes and sources are stored separately from the Profile. If the source is present but blank, check its exact file path, the mount that supplies it, and whether the account running OBS can read it.
Does exporting an OBS Profile back up my scenes and media files?
No. A Profile holds stream, video and output settings, while scenes and sources belong to a Scene Collection. Export the Profile and preserve the Scene Collection separately; keep the referenced media files available at their configured paths as well.
Will Loop make a missing video play again after reboot?
No. Loop repeats a file that OBS can access, and Restart playback when source becomes active changes when playback begins. Neither setting restores a missing file, mount, collection or permission.
Can I guarantee that OBS and YouTube will resume the same live broadcast after a server restart?
No restart procedure can be presented here as a guarantee of that outcome. Test your OBS setup before the broadcast and check current official YouTube Live guidance for how to manage an interruption.