Auto-mounting makes a USB storage partition available at a chosen path after your Raspberry Pi starts. It does not start playback, encode media, or begin a YouTube Live broadcast; those need separate applications and configuration.
For a predictable workflow, identify the partition by its UUID, mount it at a fixed directory, and test that the directory is available after reboot. Then point your media or encoder workflow at that path and test the broadcast settings separately.
What auto-mounting does and does not do
A mounted drive is storage that the operating system has attached to a directory in its file system. If your video is on the USB drive and it is mounted at /mnt/stream-media, a program with permission to read that directory can access the file there. The directory becomes the stable reference point; the drive itself may be assigned a different device name at startup.
Mounting does not decide which file to play or how to play it. It does not capture a camera, loop a playlist, encode audio and video, connect to YouTube, or keep a stream online. Treat these as distinct steps: make the media available, configure the playback or capture application, configure an encoder and its YouTube connection, then test the result.
Some Raspberry Pi OS desktop installations automatically mount common filesystems at a label-based path under /media/pi. That can suit a desktop workflow if the application can use the path created for the particular drive. Raspberry Pi OS Lite does not provide desktop automounting, and a changing label-based path may not suit a service or script that expects the same location each time. For a known path, configure an explicit mount.
Raspberry Pi's external storage documentation describes using /etc/fstab to define where storage is mounted when the system starts. This guide follows that general approach, but filesystem support, helper packages, and permission behaviour depend on your OS release and the filesystem on the partition. Check the documentation for your system if a mount option or filesystem type is unclear.
Identify the USB partition and its UUID
Connect the drive and inspect what the system can see before editing configuration. Run:
sudo lsblk -o UUID,NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL,MODEL
Read the output as a set of clues rather than assuming the first listed disk is yours. Match the partition by its capacity, filesystem type, label, model, and current mount point. A USB disk may contain more than one partition, and it is the intended partition—not necessarily the whole device—that usually needs mounting.
You can also use sudo blkid to display filesystem identifiers. Record the UUID for the partition you mean to use and confirm its filesystem type. Do not copy a UUID from an example or guess a name such as /dev/sda1: device names can change when devices are attached in a different order. Raspberry Pi's documented approach uses the UUID, which identifies the filesystem more consistently than an assumed /dev/sdX path.
If the partition is already mounted automatically, note where it is mounted and whether you can see the intended files. Do not attempt to mount the same partition on a second path while it is in use without understanding the consequences. The eventual fixed directory should be used by the application, but the contents must actually be present on the mounted partition rather than merely in the empty directory beneath it.
If you cannot tell which partition holds your media, pause here. Checking the drive from a desktop file manager or inspecting the output with someone familiar with Linux is safer than editing /etc/fstab for a guessed device. The commands below assume you have already identified the correct UUID and filesystem.
Choose a fixed mount path
Choose a clear path that you will also use in the playback or encoder configuration. For example, /mnt/stream-media says what the directory is for and is independent of a drive label. Create it if needed:
sudo mkdir -p /mnt/stream-media
The directory must exist and be empty before the partition is mounted there. If it already contains files, mounting a drive over it will hide those files for as long as the drive remains mounted; they are not copied onto the USB drive. Check it first with ls -la /mnt/stream-media. If you find files you need, move them or choose another empty directory before proceeding.
A fixed path is useful when a script, media player, or encoder configuration refers to a file by location. For instance, an application might be configured to read /mnt/stream-media/playlist.m3u or a particular video within that directory. Use the actual file name and path on your drive. The path is not a guarantee that the file is playable: the application still needs to support the media format and have permission to read it.
Configure mounting at boot
Before changing /etc/fstab, make a backup and keep a way to undo the edit. For example:
sudo cp /etc/fstab /etc/fstab.backup
Open /etc/fstab in an editor with administrator privileges, such as sudo nano /etc/fstab, and add one line for the identified partition. Raspberry Pi's documentation gives this pattern:
UUID=5C24-1453 /mnt/mydisk fstype defaults,auto,users,rw,nofail 0 0
That UUID and mount path are examples only. Replace the UUID with the one you recorded, /mnt/mydisk with the directory you chose, and fstype with the filesystem type shown for the actual partition. Preserve the spacing between fields. Do not paste the sample unchanged: it will not identify your drive, and an incorrect filesystem type or path can prevent the entry from working.
The nofail option is intended to let the system start even if the storage device is not attached. That may be useful for a removable drive, but it does not make the media available when the drive is absent. If the encoder starts without the drive, its input may be missing. You will need to decide how your playback workflow should behave in that situation and test it.
Filesystem details matter. Raspberry Pi's documentation notes that FAT or NTFS entries should add ,umask=000 immediately after nofail when full read/write access for every user is wanted. That is a broad permission choice, not a universal default: it allows all users read and write access. Prefer access limited to the account or application that needs the media where practical, and consult the relevant documentation for your OS and filesystem. Ownership and permissions are not handled identically by every filesystem, and exFAT support may require additional packages depending on the system. Do not add options for a different filesystem by guesswork.
After saving, review the line for spelling, separators, UUID, mount path, and filesystem type. A typo in a boot-time mount configuration can cause confusing startup behaviour. Keep the backup so that you can restore the previous file if validation fails.
Test the mount and reboot behaviour
Validate the entry before rebooting:
sudo mount -a
findmnt /mnt/stream-media
ls -la /mnt/stream-media
mount -a asks the system to process configured entries. If it reports an error, fix the configuration before restarting. findmnt should show the partition mounted at the path you selected. Listing the directory should show the files on the drive; if it shows an empty directory, check that the intended partition is mounted and contains the media.
Test with the account that will run the playback or encoder application, not only with sudo. A root-owned check can succeed even when an ordinary user cannot read the media. Try listing or opening a representative file as that account. If the application runs as a service under a different account, check access for that account too.
Once the mount works, reboot and repeat the checks. Confirm that the same path is mounted and the media is visible. If removable-device startup matters, test the case where the Pi boots with the drive disconnected. With nofail, the system is expected to continue starting, but the media path will not contain the drive's files until it is attached and mounted. Confirm how your applications behave rather than assuming they will recover on their own.
A successful reboot test verifies the mount, not the whole broadcast. It says nothing about whether a video decodes smoothly, whether an encoder can sustain a selected format, or whether the network can carry the outgoing stream. Keep those checks separate so that a playback or connection fault is not mistaken for a storage fault.
Point the YouTube encoder workflow at the media path
With the mount confirmed, configure the relevant playback or encoder input to use the file under /mnt/stream-media. The exact steps depend on the application. A playlist-based workflow might reference a playlist stored on the USB drive; another setup may use a file chooser or a capture application that reads media from the directory. Enter the path that exists on your Pi, not a desktop path copied from another computer.
Then configure the YouTube connection separately in YouTube Live Control Room and in the encoder. The encoder needs the appropriate stream URL and stream key. Treat the key like a password: do not put a real key in a public tutorial, terminal transcript, or screenshot. For the account and access steps, see this guide to using a YouTube stream key with two-step verification enabled.
YouTube's live encoder guidance covers RTMP or RTMPS, supported video codecs, audio, and recommended settings. YouTube recommends RTMPS. Its recommended H.264 bitrate examples include 10 Mbps for 1080p at 30 fps and 6 Mbps for 720p at 30 fps; these are YouTube platform recommendations, not measurements of Raspberry Pi performance. Do not assume your particular Pi can encode any listed setting. Select settings your encoder and connection can sustain, and check the encoder and device documentation for your specific setup.
Test a representative section of your actual content, including audio and moving video. YouTube specifically advises testing before a live stream with audio and movement similar to the planned broadcast. Check the encoder preview and YouTube's stream health, and make a test broadcast before relying on the setup for an event or overnight channel. If the media disappears after a reboot, investigate the mount; if it is available but the stream has no audio or drops frames, investigate the playback, encoder, and connection separately. For an OBS playlist workflow, keeping a YouTube stream running when OBS loses its media source addresses a different failure point from mounting.
A fixed directory also makes it easier to distinguish a media-path problem from an encoder problem during troubleshooting. If playback stops after a restart, check whether the drive is mounted at the expected path and whether the application account can read the content. If both are true, continue with the application's logs and preview rather than repeatedly changing the mount configuration.
Check permissions and mount failures
When a file is visible in a directory but an application cannot open it, check both the mount and the account. Use findmnt /mnt/stream-media to confirm that the USB partition is mounted there, then inspect permissions with ls -l /mnt/stream-media and, if needed, the files within it. The user who launched the application may differ from the account you use at the desktop or shell.
A permission fix depends on the filesystem and how it is mounted. On some filesystems, ownership and mode bits are represented through mount options; on others, ordinary file permissions behave differently. Avoid applying broad writable access simply because a read failed. Determine which account needs access, check the filesystem's documented options for your OS release, and make the smallest suitable change. Test again as the application account.
If mount -a reports an unknown filesystem or helper, verify the FSTYPE value and check whether the relevant filesystem support is installed for your operating-system release. If the UUID is not found, reconnect the intended drive and compare lsblk or blkid output with the entry. If findmnt shows no mount at the target path, check that the directory exists, is empty before mounting, and matches the path in /etc/fstab exactly.
If startup behaviour changes after an edit, restore the backup rather than making several unverified changes at once. Correct one issue, run sudo mount -a, and check the result before rebooting again. Keeping a note of the UUID, filesystem, mount path, and any options you deliberately chose makes later replacement or troubleshooting clearer. It does not remove the need to re-identify a new drive if you replace the storage device.
For long-running channels, test recovery as well as normal operation. The mount is only one part of the chain: media availability, playback, encoding, network delivery, and YouTube's ingest each have distinct failure modes. If the stream itself goes offline on a home server, the router and overheating troubleshooting guide covers a network-side issue that a correct USB mount cannot fix.
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
Does auto-mounting a USB drive start my YouTube stream?
No. Auto-mounting makes the drive's files accessible at a path after boot. You still need a playback or capture workflow, an encoder configured for YouTube, and a separate test of the live connection.
Should I use a label-based path or a fixed mount path?
A desktop installation may mount a drive under a label-based path in /media/pi, which can be sufficient if your application can follow it. Use an explicit fixed path when a script or application needs a known location or when you use Raspberry Pi OS Lite, which does not provide desktop automounting.
Can I use the same /etc/fstab line for any USB filesystem?
No. The UUID, filesystem type, and suitable mount options must match the partition and operating system. Check the actual filesystem and its support before editing the entry, and avoid copying example values unchanged.
What should I check if the files are mounted but playback fails?
First verify the expected path is mounted and that the account running the application can read the files. If both checks pass, investigate the application's media support, playback configuration, encoder preview, and stream health; mounting alone does not test those parts.