Volume on Syno Docker?

Currently reading
Volume on Syno Docker?

3
0
NAS
DS1618+
Operating system
  1. Linux
  2. Windows
I've installed eerotal/LibreSignage on my NAS and it is working. I'm still testing it but before I start using it for real, I'd like to make sure I have the volume installed properly.

According to the documentation, I should run the docker as follows:

Code:
docker run \
    -d \
    -p 80:80 \
    --mount source=ls_vol,target=/var/www/html/data \
    eerotal/libresignage:latest

I'm struggling to get the --mount source=ls_vol,target=... part defined in the DSM docker. How do I do that? When trying to use the mount path, it does not work. I get the same problems as discussed here. Is there any way I can do this with the GUI on the NAS?
 
Is there any way I can do this with the GUI on the NAS?

Screenshot 2020-07-20 at 09.14.20.png


Have you tried it like this? So select a local folder on your nas (left side) and enter the mount path like in the documentation/image.
 
From the linked github discussion it appears that the docker image comes pre-populated with the web site files in /var/www/html/data. When you use that folder as a mount point to a local NAS folder (ls_vol) you obscure the container's files with whatever is in ls_vol... i.e nothing, and so no web pages.

What you can do to fix this:
  1. First mount the NAS's local folder to a different point in the container (this creates the new point in the image too): e.g. /var/www/html/data_temp
  2. From DSM docker, use the terminal access to get to the container's command line.
  3. Use command cp -r /var/www/html/data/* /var/www/html/data_temp/ (recursive copy) to copy the files to the NAS's local folder.
  4. Stop the container and edit the configuration to change the mount point from the temporary .../data_temp to the .../ data folder.
  5. Restart the container and hopefully it now works.
 
Thanks for the help.

Yes, when I tried Rusty's suggestion, then I can't log on anymore.

I tried the approach by Fredbert. I can mount a data_temp directory, but every time I try to get to the terminal window, the container shutsdown immediately. I even tried it via SSH and try the docker container attach.

Code:
root:/volume1/@docker/volumes# docker container attach a47c525b6b95
[Mon Jul 20 09:52:31.132800 2020] [mpm_prefork:notice] [pid 1] AH00170: caught SIGWINCH, shutting down gracefully
root:/volume1/@docker/volumes#

I guess I will need some help from the developer on that one.
 
Last edited:
Terrible image design. Beginner friendly images usualy have a mechanism, where they store the required files in a temp folder and check in their entrypoint script if the target folder is empty. In case it is empty they copy the data from the temp folder to the target folder.

You can create a volume backed by a bind like this:
docker volume create --driver local -o o=bind -o type=none -o device={your-local-path} ls_vol

The copy-on-create mechanism only works, if the device folder is empty the first time the container is created. if data exists in the device folder, the data from the containers target path will not be copied into the device folder on the host.

Make sure to get the device option right, as there is no way to update a declared volume. In case you need to "fix" the local path, you will need to remove and re-create the volume. In case of a bind backed volume, a deletion of the volume declaration will only delete the declaration, not the content inside the (device) folder.

I never used the --mount option. Give it a try, if it doesn't work you can still replace the option with -v ls_vol:/var/www/html/data

Side note: recently I had a look into QNAP's docker version, which is able to create (real!) volumes directly from the ui.
 
Thanks for all the replies. After meddling and trying for quite a few times, I ended up installing the docker from the command line with an SSH connection.
When I first tried that, the docker wouldn't show up in the GUI, so I thought that's not a good solution. But then when I tried again, it did and it seems to be running just fine.
The drawback is still, that the persistent directory is not visible/accessible from the GUI, but at least it's there. So I guess it's sort of ok.
 

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.

Similar threads

Well, that's the reason as you already noticed. So you haven't migrated the @docker content? Do you have...
Replies
5
Views
1,878
This looks interesting and not so inventory dependent... https://github.com/davideshay/groceries
Replies
8
Views
1,208
  • Question
Stop the container and then select it in the UI. Click the Edit button to change some of the container...
Replies
3
Views
5,962
  • Question
Well I have been busy today so didn't have time to answer sooner, but @one-eyed-king said it all. So in...
Replies
4
Views
1,606
No, I just mentioned docker.sock because in my ignorance thought that had something to do with my problem...
Replies
2
Views
2,537
Welcome and good luck! Also welcome to the forum!
Replies
8
Views
3,421
Limiting access to UID/GID of the bind-mount "volume" is of course the prefered approach. Though this is...
Replies
5
Views
11,601

Welcome to SynoForum.com!

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

Registration is free, easy and fast!

Back
Top