Stymied with Fireshare

Currently reading
Stymied with Fireshare

Telos

Subscriber
2,544
823
NAS
DS418play, DS213j, DS3622+, DSM 7.2.4-11091
Last edited:
Having seen many posts seeking a means to stream media without necessitating a download, I ran across Fireshare.

So I spun up a Docker container and added a few MP4 videos, using this docker-compose file:
Code:
version: "3.5"
services:
  fireshare:
    image: shaneisrael/fireshare:latest
    container_name: fireshare
    ports:
      - 8888:80
    volumes:
      - /volume1/docker/fireshare/data:/data
      - /volume1/docker/fireshare/processed:/processed
      - /volume1/testing/clips:/videos
    environment:
      - ADMIN_PASSWORD=admin
    restart: always
When launched, everything looks fine. I can rename videos, and add metadata. But if I click on a video, it won't play in any browser (I tried four). I get a browser notification saying, "No video with supported format and MIME type found." Yet if I drag the MP4 into a blank browser window, it plays... ruling out a codec issue.

The same thing happens with a video share link.

I'm a bit baffled by what seems to be a permissions issue. I tried adding
Code:
user: 1028:101
to the compose file, but that resulted in critical errors preventing the home page from loading.

Has anyone tried running this on a Synology NAS? Appreciate any inputs!
 
I'm a bit baffled by what seems to be a permissions issue. I tried adding
Code:
user: 1028:101
to the compose file, but that resulted in critical errors preventing the home page from loading.
The Dockerfile has no USER instruction - which is the user which `user:` would override - this image doesn't support it.

Though it adds a nginx user, that is used by the installed nginx. The nginx instance in the container serves everything expect /api and /w which are forwarded to the flask application run in by gunicorn.

My educated guess is that you a) either need to allign the folder permissions to the uid/gid the nginx work processses use OR create your own Dockerfile which adds the USER instruction to support an override using user:.

I am not sure if I'd run a container where the main application runs with root permissions... Instead I would raise an issue and let the image maintainer implement the necessary stuff used to run the application with an unprivliged user.
 

Telos

Subscriber
2,544
823
NAS
DS418play, DS213j, DS3622+, DSM 7.2.4-11091
Thanks for that. My attempt with user: was suggested by the developer after I mentioned a lack of PUID/PGID environmental variables. I'll pass along your suggestion..
 

Telos

Subscriber
2,544
823
NAS
DS418play, DS213j, DS3622+, DSM 7.2.4-11091
As it turns out, the developer was responsive to these inputs. Although he has no Synology test unit, we were able to work through the issues tied to `root` ownership.

The next issue I faced seems related to Synology, or "yours truly". When mapping persistent volumes, all the Fireshare config stuff is in my shared folder "docker" ... but my videos are in a folder"clips", located in a separate shared folder. Until I moved my videos path to the docker shared folder, I could not play the videos, even though the clips folder was owned by my PUID user.

I don't know if this is a path issue or a permission issue that prevent video play across shared folders. I do recall a related problem I had when I set up sonnar, qbittorrent, and Plex, that was resolved with a common shared folder.
 
Have you checked if ACL's are responsible for that behavior? If the ACL's prevent access, you could have all the correct UID/GID and unix files permissions of the world, and it would still not work ^^

Containers have no idea about Syno's ACL extension, but the Syno that tries to enforce them on file access level does :D
 

Telos

Subscriber
2,544
823
NAS
DS418play, DS213j, DS3622+, DSM 7.2.4-11091
Have you checked if ACL's are responsible for that behavior?
I may be ignorant here. Since I'm running the container with an admin PUID, I checked the "Permissions Inspector" for that user on the original shared folder I was using, and it showed all permissions checked.

I suspect you are referring to something entirely different, so possibly I'm lost at sea without an oar. Exactly where should I look, and what am I looking for? Thanks!
 
Last edited:
The Syno ACL's Iam refering to are set in the "Control Panel" -> Shared Folders -> {select your share} -> "Edit"-button -> Tab "Permissions".

Check the SynoACL's of the folder you have permission problems with:
Code:
find /volumeX/share/whatever/path -exec echo "{}:" \; -exec synoacltool -get {} \;

A container does not understand any of it and does not access the files the way the Syno ACL's expects it to access the files, therefore the Syno ACL denies the permissions to access the files. This is regardless of the unix file permissions, which of course still have to be correct .

If you remove the ACL's, every configured permission from the "Permissions" tab will be wiped out for that share (=all folders, subfolders and files in it)! Once you understand and accept that implication, you can replace the `-get` part of the above command with `-del` to remove the ACL's. As a result the folder and all subfolders and files in it will only have unix file permissions (which remain unchanged by the command).

In case of doubt: do not execute the `-del` command :D
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Trending threads

Top