Access SMB share and add it to a library

[hapylestat 10]

On 12/1/2023 at 10:38 PM, Carlo said:

Curious how you are mounting these? 

 

 

For local storage I'm mounting it like .....

/mnt/fakevolumes/Movies/volume1/...

/mnt/fakevolumes/Movies/volume2/...

 

And for samba...something like:

/mnt/samba/Movies/

....

 

To mention, i'm running emby in podman container(not the one from dockerhub) with mounted gpu & volumes and mounting CIFS before starting emby:

# podman logs emby-server
!!! NON-Root environment detected, using sudo.
Mounting SAMBA Volumes...
  ==> Mounting (sudo) "//nas/Clips" to "/mnt/samba/Clips"...
[EXEC] sudo -h 127.0.0.1 mkdir -p /mnt/samba/Clips -> [ok]
[EXEC] sudo -h 127.0.0.1 mount -t cifs //nas/Clips /mnt/samba/Clips -o user=,password= -> [ok]
  ==> Mounting (sudo) "//nas/Music" to "/mnt/samba/Music"...
[EXEC] sudo -h 127.0.0.1 mkdir -p /mnt/samba/Music -> [ok]
[EXEC] sudo -h 127.0.0.1 mount -t cifs //nas/Music /mnt/samba/Music -o user=,password= -> [ok]
Starting server ...
Info Main: Application path: /opt/emby-server/system/EmbyServer.dll
Info App: Setting default culture to en-US
Info Main: Emby

 

It somehow works and are manageable with only one drawback, mounted folders could lose connection (on remote restart for example or router restart), and it would require container restart to remount folders. That's why implementation on emby side would be preferable.   At the moment some connection checker is required in the background to remount these static cifs mounts...  

Edited December 10, 2023 by hapylestat

[hapylestat 10]

And probably the latest update on the topic, since nothing done on emby side.....there's a solution on a docker compose side -easy and effective(but not without a downsides).

- Manage your emby via docker compose

- add samba mounts as below:

volumes:
    cifs_clips:
      driver: local
      driver_opts:
        type: cifs
        device: //some.nas.server/with/nas/folder
        o: username=${NAS_USERNAME},password=${NAS_PASS},vers=3.0

services:
  emby:
    ....
    restart: always
    volumes:
      - cifs_clips:/mnt/samba/Clips:ro

 

 

Downsides: if the cifs mount is not there or nas is still not loaded, container wouldn't start

[Luke 42077]

22 minutes ago, hapylestat said:

And probably the latest update on the topic, since nothing done on emby side.....there's a solution on a docker compose side -easy and effective(but not without a downsides).

- Manage your emby via docker compose

- add samba mounts as below:

volumes:
    cifs_clips:
      driver: local
      driver_opts:
        type: cifs
        device: //some.nas.server/with/nas/folder
        o: username=${NAS_USERNAME},password=${NAS_PASS},vers=3.0

services:
  emby:
    ....
    restart: always
    volumes:
      - cifs_clips:/mnt/samba/Clips:ro

 

 

Downsides: if the cifs mount is not there or nas is still not loaded, container wouldn't start

Hi, what makes you think nothing has been done on the Emby side?

We do still recommend mounting it on the system though.

[hapylestat 10]

1 hour ago, Luke said:

Hi, what makes you think nothing has been done on the Emby side?

We do still recommend mounting it on the system though.

well, mounting it in the system was like "workaround" in 2017 year post with consideration to implement it on the emby level. And the change done, it is now recommendation  

 

And the problem with mounting it in any external way still exists:

- If the remote is offline, container wouldn't start or the folder would be unmounted (there no external samba mount managers, to make it sustain reboots or remote target reboots). Mounting it on fstab level brings another set of problems as well.

- mounting via composer, exposes remote smb permissions, well, in a same way as to do it via fstab.

- on emby side such mounts require watchdog to be disabled with manual rescan required, so the index would not be removed if remote would be disconnected.

 

Edited December 9, 2024 by hapylestat

[Carlo 4560]

Hi,

Emby recommends mounting a share to the system instead of using a URL share for libraries because it ensures better compatibility and performance. Here are a few reasons why:

• Full Feature Support: Mounting a share allows Emby to utilize all features of the SMB protocol, including various versions and configurations. This ensures smoother and more reliable access to media files.

• Reduced Bandwidth Usage: By mounting the share locally, Emby can access media files directly without needing to pass through additional network layers, which can save bandwidth and improve streaming performance.

• Stability: Local mounts are generally more stable and less prone to errors compared to URL shares, which can sometimes fail or become inaccessible due to network issues.

• Ease of Management: Managing local mounts is often simpler and more straightforward, especially when dealing with permissions and access controls.

Overall, mounting a share to the system provides a more robust and efficient way to manage and access media libraries within Emby.

[jesmo 0]

"Emby recommends mounting a share to the system instead..."

Where can I find the instructions? I had previously done it using a remote folder mount as described here. But that always causes problems.

[Luke 42077]

On 11/9/2025 at 7:04 AM, jesmo said:

"Emby recommends mounting a share to the system instead..."

Where can I find the instructions? I had previously done it using a remote folder mount as described here. But that always causes problems.

Hi, in Synology you can mount by creating local volumes, right?