Stymied with Fireshare

Currently reading
Stymied with Fireshare

4,027
1,378
NAS
DS4l8play, DS202j, DS3623xs+, DSM 7.3.3-25847
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.
 
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
 
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
 
I ran the commands on the two folders... and they gave somewhat different results

The folder that works:
Code:
find /volume1/docker/fireshare/clips -exec echo "{}:" \; -exec synoacltool -get {} \;
/volume1/docker/fireshare/clips:
ACL version: 1
Archive: is_inherit,is_support_ACL
Owner: [ADMIN1(user)]
---------------------
         [0] group:administrators:allow:rwxpdDaARWc--:fd--  (level:2)
         [1] user:USER1:allow:rwxpdDaARWc--:fd--  (level:2)
         [2] user:ADMIN1:allow:rwxpdDaARWc--:fd--  (level:2)
         [3] owner::allow:rwxpdDaARWcCo:fdi-  (level:2)
         [4] user:ADMIN1:allow:rwxpdDaARWcCo:----  (level:2)
         [5] everyone::allow:r-x---a-R-c--:fd--  (level:2)

The folder that does not work:
Code:
find /volume1/testing/clips -exec echo "{}:" \; -exec synoacltool -get {} \;
/volume1/testing/clips:
ACL version: 1
Archive: is_inherit,is_support_ACL
Owner: [USER1(user)]
---------------------
         [0] group:administrators:allow:rwxpdDaARWc--:fd--  (level:1)
         [1] user:USER1:allow:rwxpdDaARWc--:fd--  (level:1)
         [2] user:ADMIN1:allow:rwxpdDaARWc--:fd--  (level:1)

Can you help me understand why? And how I can change the folder that does not work for one that does.

Just for fun... here's a Fireshare link:


Just FYI... It supports Open Graph... but I've yet to "see" that.
 
To be honest, ACL's are not my strong suite. I completly removed them on the shares I bind into containers.
Though, if i'd put my money one it, I'd try to replicate this one on the share where it's not working:
Code:
         [5] everyone::allow:r-x---a-R-c--:fd--  (level:2)

Like I said, a container does not know how to set the ACL relevant while accessing the folder, as such I would expect the everyone setting to be the key to success.
 
I'd try to replicate this one on the share where it's not working
Well... that didn't go as expected.

I went to the working folder and examined advanced permissions to see what "everyone" enjoyed.

Next, I went to the nonworking folder, but found I could not change the advanced permissions for "everyone". Then I saw the checkbox to allow advanced permissions. As soon as I OK'd that, the shared folder dropped out of File Station. Good grief.

In Control Panel I unchecked "advanced permissions", and the folder reappeared in File Station. Still, I cannot see how to assign "everyone" any permissions in the nonworking folder, either in File Station or in Shared Folder Edit.

I'll need to retrace my steps and review the wondrous Knowledge Center for clues.

EDIT1: OK... figured it out. Later I'll add back videos and see if Fireshare can read those.
 
In the working folder, "everyone" had full "read" rights. After adding that permission to the non-working folder ("everyone" had no "rights" that were checked), and creating a new container, the videos then behaved as they should.

So... even though the container ran with administrator group rights, and the videos were installed in a folder which the administrator owned and had full rights to... the container could not play the file until "everyone" had "read" rights.

O the headache I have coming on.

Thanks for pointing me in the right direction @one-eyed-king 🍪
 
Now that I have this "figured out". I needed to locate my shared clips under my media shared folder. And again, simply creating a subfolder to a shared folder failed to have the necessary default permissions. I added "Everyone" with "read" rights, resolving the issue.

Life shouldn't be this complicated for a Synology user. Why, O why?
 
So... even though the container ran with administrator group rights, and the videos were installed in a folder which the administrator owned and had full rights to... the container could not play the file until "everyone" had "read" rights.
I tried to explain it:
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
But seem to have failed. The only exception to what I wrote above seem to be the permissions for "everyone", which if you think about it make sense and matches your observation.
 
... and I continue to fail to make myself clear.

The Syno filesystem has access restrictions based on ACL which are not part of the unix file permissions, it's more of an external extension. A container on the other side does know nothing about the ACL, thus it is not able to provide the extenden information required to authorize the access against the Syno ACLs.

The expectation, that just because you use the same UID/GID as the folder owner, is wort nothing if ACL based access control is sitting on top of it - which it does. Containers are simply imcompatible with Syno ACL, as it the process is only able to provide the UID/GID information, but not the additionaly required ACL information the Syno access control expects when accessing the files.

Thus said: no it's not enough to use the UID/GID of the admin.

The ACL's need either to be removed completly or allow everyone access. This is not special to this container. This is a generall "thing" on Syno(!) and probably even other systems that uses ACL's.
 
Well... that opened my eyes! Thank you.
The ACL's need either to be removed completly or allow everyone access.
Is that done simply somehow? And what are the drawbacks? Is /homes the only shared folder that "benefits" from ACL?

Why did Synology choose this?

As an aside... does the "http" group have any involvement here (mine has no permissions for any shared folder)?

Thanks!
 
I already wrote about how it's removed (see: Stymied with Fireshare). But you need to understand that you solely rely on unix file permissions than - regardless if you access the folders/files from the syno or thru the share!

ACL's are the better and more nuanced way to grant access permissions. Synology would be crazy to not use it!
Docker was never designed to work with ACL's - which in reality you will not find on productive servers running docker or kubernetes. It's just a clash of two worlds - one that requires nuanced access control, and the other that does not require or care at all for it.

What do you mean by http group? Either the process inside the container is running with your provided UID/GID or it is not. Not sure how to respond do that
 
Last edited:
Erata: I was wrong, Docker and ACL's can play nice together.

For instance on an Ubuntu 20.04 host using latest Docker-CE with the overlayfs storage driver, the acl's get propagated to a container and when you check them with getfacl, you can actualy see the acl's on the folder!

Test it yourself on Ubuntu:
Code:
# first without acl
sudo mkdir /opt/test
sudo docker run -ti --rm -v /opt/test:/test  ubuntu bash -c 'apt update && apt install -y --no-install-recommends acl && getfacl /test'

# set default acl for group other
sudo setfacl -d -m o::rwx /opt/test

# confirm acls are present 
sudo docker run -ti --rm -v /opt/test:/test  ubuntu bash -c 'apt update && apt install -y --no-install-recommends acl && getfacl /test'

# cleanup
sudo rm -rf /opt/test

output of the second docker command:
Code:
...
getfacl: Removing leading '/' from absolute path names
# file: test
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::r-x
default:other::rwx

You can see that the default acl's are set and propagated into the container, so my statement that ACL are generaly not supported by Docker was false. The first docker run command will give the same output like the docker run command below for Synology does, so I am not going to paste it here as well.

Though, the same thing is not working on Synology using latest Docke-CE with AUFS storage driver. The acl's are just not present. So it is either the AUFS storage driver, or Syno's own acl implementation that prevents it from working.

Test on Syno:
Code:
docker run -ti --rm -v /whatever/folder/that/has/acl:/test  ubuntu bash -c 'apt update && apt install -y --no-install-recommends acl && getfacl /test'

change /whatever/folder/that/has/acl to the folder you want to test. As a result you will only see unix file permissions.

As we already have acl on folders, there is no reason to check without acl or set acl's during the test case.

Output of the docker run command:
Code:
...
getfacl: Removing leading '/' from absolute path names
# file: test
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

Underneath "other", the acl's should have been listed, but they are not.

Can someone who uses the BTRFS storage driver perform the Syno test and see if it changes things? If not, then either the BTRFS storage driver is also affected, or Synology went ahead and modified enough of the acl code to make it incompatible with the default implementation.
 
What do you mean by http group?
I probably should not have tacked that on? I have 3 default groups (by Synology): user, http, administrator. I have no idea why group http exists. It has no members, and it has no rights. I can find no information on it in the Knowledge Center. Normally, I would delete detritus such as this, but fear of breaking something unknown stopped me from doing that.

While I was struggling to sort out why Fireshare videos would not play on my browser, I wondered if the lack of http members or rights, might relate to my issue.

I'll drop the http question. Thanks for all else.

But regarding ACL...
A container on the other side does know nothing about the ACL, thus it is not able to provide the extenden information required to authorize the access against the Syno ACLs.
I now understand. But curiously, I tried to add ACL Read permissions to the administrator whose PUID/PGID is specified (instead of "Everyone"), but apparently that can't be done. I think I need a beer now... but it must wait until after I handle some errands.
 

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!

Back
Top