Using official Docker with Synology Docker GUI

Hi

Anyone been able to get ttrss up and running using fox’s docker container and the synology docker GUI. I’m basically having to manually carry out all the steps because i can’t use docker-compose. So far I’ve set up the database, created the app container, created the web container and linked them together. I can now run ttrss successfully but the only part missing is updating the feeds.

Am I right in thinking I should set up another ttrss-web container, linking it to the app container and run the updater.sh command on startup?

No doubt Fox will hit his forehead with his palm so i didn’t dare post it anywhere other than unsupported :smile:

I think you’re on the right track, updater uses same image, the only difference is the entrypoint script.

Thanks Fox.
Anyone successfully run this using the Synology GUI?
I’ve tried updater.sh and /src/app/updater.sh for the command but get the following error message

args:2 - Error during parsing: Unknown directive ‘/src/app/updater.sh’

any particular reason you’re doing this through the web gui? i think it would be a lot easier to enable SSH on synology and run docker-compose directly.

Only reason being all my other dozen or so containers were set up through the GUI so that was my starting point. If i don’t manage to get my head round the execution command I’ll try docker-compose.
Appreciate the response

i’ve never even seen this gui but correct script location (inside the container) is /updater.sh.

Hi

Has anyone managed to get the updater up and running on anything other than docker-compose, I’ve played around with Portainer and interestingly (for me anyway) I’m getting the exact same error message using the command /updater.sh (unknown directive)

Is the entry point in docker hub definitely correct as it can’t find the updater script?
Dockerhub
image
Portainer Error
image
Portainer instructions
image

you need to use a separate entrypoint, not pass /updater.sh as an argument to caddy which is what you’re seemingly trying to do.

e: also there’s no /updater.sh in the caddy (web) image.

I feel like an idiot here, I’d created the wrong container for the update container (web rather than app). If anyone is as stupid as I am then this screenshot may help.
Thanks to Fox for showing me some patience

Note that I had to change the execution command entry point to /bin/sh and I also had to link the update container to the db but the docker-compose in dockerhub suggests that the update container is linked to the app only

image

image

If it’s of interest to anyone I’ve now written a blog post from start to finish
https://blog.oliroe.com

Since I glanced through your blog post as reference, may I suggest some updates based on steps I took to get tt-rss running with Synology’s Docker GUI.

  • For the DB container, mentioning that you can’t use the container’s port of 5432 because DSM uses that port for its internal postgres instance.
  • For the APP and UPDATER containers, remove the defaulted entry under ports. Its not needed since the containers are linked.
  • For the UPDATER and WEB containers, the mount should point to the same folder on the NAS that was used for the APP container. Also, this mount can be read-only for the WEB container.

The APP Container fails to run. I am getting the following errors in the APP log:

db:5432 - accepting connections (that’s good!)

  • id app
    id: unknown user app
  • addgroup -g 100 app
    addgroup: gid ‘100’ in use

Very strange as I am using the correct PUID and GUID for the Synology user admin account that I am using to set up the containers - I reverified them via SSH. Those values (User 1026, Group 100) are being used and working for my HOOBS container perfectly. Also - I am obviously using the same User and Password in the POSTGRES_USER in the DB Container as the DB_USER in the App container (passwords as well of course). Can’t figure this one out!

Any help would be great.

Thanks!

Rye

it was a mistake making those configurable because of people like you specifically.

i’m going to assume that you decided to change OWNER_GID because for some reason you thought that it should correspond to your host group id. it shouldn’t, this user and group is used inside the container. it’s not really relevant to the outside world in any way whatsoever.

while you were doing this you, however, changed it to the value (100) which is reserved to some default system group in alpine, thus breaking everything.

in the future don’t start changing things if you don’t know what they do.

Hi Fox,

Not sure what you are referring to or why there is any negativity coming my way.
I used Oliver Roe’s instructions at : https://blog.oliroe.com/ .

In the APP CONTAINER section, the environment variables have to be set as follows:
DB_PASS – the password you used in the db container
DB_USER – the user you used in the db container
DB_NAME – the db name you used in the db container
DB_HOST – db
DB_TYPE – pgsql
OWNER_GID – see https://blog.oliroe.com/2020/04/17/how-to-obtain-your-puid-pgid/(opens in a new tab)
OWNER_UID – as above
SELF_URL_PATH – the address to be used to access the app in the fomat http(s)://ADDRESS:XXXX(port number if reverse proxy isn’t being used)/tt-rss/

I am getting the “unknown user” and “gid in use” errors based on MY PUID and GUID as per the instructions above. I already had them from Hoobs Docker installation and reverified.

Again - your response is unclear to me. If I erred, can you please advise on the correction. That was the intent of my post!

Thx

what an amazing response. let’s recap your accomplishments so far:

  • you blindly followed a vague tutorial, without thinking, until you ran into an error
  • you reposted the error message here, without thinking
  • then you blankly ignored my post which explained why the error happens and exactly what you did wrong, instead deciding to repost something again

unless you want someone here to literally log into your synology unit and fix your broken setup for you, i’m not sure if there’s any way to help you. how can you help someone who absolutely refuses to put any effort whatsoever nor even attempt to understand what’s going on?

i’m honestly amazed how people can function like this, seemingly entirely on auto pilot, always unaware.

Set the OWNER_GID and OWNER_UID variables to 1000 as they are defaulted in the repository and see if it works.

Y2KSE - thank you. Appreciate it…

Fox - there are no words…

same, same :roll_eyes:

The one impact is the directories and files on the host system get assigned those UID and GID which could give access to an undesired user. In that sense, it would be useful to assign GID 100 which is the default users group on Synology but appears to already exist in the container causing the addgroup to fail.

everything is supposed to be stored on a docker storage volume so this isn’t really an issue.