I had the impression with Omv 5 the ABSOLUTE PATH was necessary for Portainer to work but with my brand new upgrade the relative path are working without any need to change volumes.
Somebody can clarify?
I had the impression with Omv 5 the ABSOLUTE PATH was necessary for Portainer to work but with my brand new upgrade the relative path are working without any need to change volumes.
Somebody can clarify?
Not sure but I think this upgrade did not complete fully this is why with this SD, it is working this way on an other upgrade the relative paths are not working?
I had the impression with Omv 5 the ABSOLUTE PATH was necessary for Portainer to work but with my brand new upgrade the relative path are working without any need to change volumes.
Somebody can clarify?
To be clear to others you should give examples of what you mean by absolute and relative paths.
no problem! I was thinking it was explicit enough but just in case a picture is worth a thousand words.
You do not want to use any /sharedfolders/.......host paths (what you are calling relative paths) in any docker volume or bind mounts.
So it is What I thought but one of my upgraded omv 5 was working with relative path I think the upgrade did not perform completely and in a way was giving me errors inot related to this matter like netfilter failure.
An earlier version of OMV, when upgraded in place to OMV 5 will not remove or depopulate any files or folders in /sharedfolders that were created there by the previous version of OMV. They should continue to work or cause problems just like they did in the prior version installation because it is the container configurations that still have these settings until you change them.
I do not know however, whether or not such an upgraded installation will create new folders in /sharedfolders when new shares are created (following the prior version behavior), or no longer create them (as is the default behavior in a fresh install of OMV 5). I do know that this behavior is user configurable via an environment variable setting in /etc/default/openmediavault
Regardless, there were reasons for deprecating this behavior in OMV 5. I do not have a list of these reasons and how they rank with respect to causing problems. But using /sharedfolders paths in docker volume and bind mounts is a reason, and may be a major reason.
In your first pic you have Extra arguments that contain a volume statement. This is not the place for that so delete it. It belongs in the Volume and bind mounts section and you already have it there.
You also might need another volume statement, set read only
/etc/localtime:/etc/localtime:ro
I removed the exta argument under label i put the Bind mount /etc/localtime:/etc/localtime not sure if watch tower is working the log just says time="2020-05-23T14:49:27-07:00" level=info msg="First run: 2020-05-23 14:54:27 -0700 PDT"
I have a cron job docker images -q --filter "dangling=true" | xargs -n1 -r docker rmi
but right now it does not do anything , am I missing something?
Should I put this in all my container I had /etc/localtime in volumes mount in all my container I deleted them since I did not understand the use of them, should I put them back as mount /etc/localtime:/etc/localtime ?
An earlier version of OMV, when upgraded in place to OMV 5 will not remove or depopulate any files or folders in /sharedfolders that were created there by the previous version of OMV. They should continue to work or cause problems just like they did in the prior version installation because it is the container configurations that still have these settings until you change them.
I do not know however, whether or not such an upgraded installation will create new folders in /sharedfolders when new shares are created (following the prior version behavior), or no longer create them (as is the default behavior in a fresh install of OMV 5). I do know that this behavior is user configurable via an environment variable setting in /etc/default/openmediavault
Regardless, there were reasons for deprecating this behavior in OMV 5. I do not have a list of these reasons and how they rank with respect to causing problems. But using /sharedfolders paths in docker volume and bind mounts is a reason, and may be a major reason.
Anyway i saw this post from@ryecoaaron RE: Sharedfolder but I wont change it since It does not look I need the path with sharefolders and it is working the way it is, now?
You won't know if Watchtower is working or not until you get notifications from it that it has replaced an image. Did you set up email notifications for Waychtower?
The cron job to cleanup old images won't do anything until there old unused images to clean up. You should get email when it does something.
You should be using volume mounts as suggested by the image documentation. If an image needs a localtime entry it will tell you. If it doesn't it won't.
Actually I am getting some errors I think the network is not reachable how to fix that?
Also according the instructions from https://hub.docker.com/r/v2tec/watchtower/ I should be able to pass an expreesion to clean up in the docker run
string: How can I enter s this option in portainer?
time="2020-05-23T19:59:04-07:00" level=info msg="Waiting for running update to be finished..."
time="2020-05-23T20:27:37-07:00" level=info msg="First run: 2020-05-23 20:32:37 -0700 PDT"
time="2020-05-24T06:27:47-07:00" level=info msg="Unable to update container /Plex, err='Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on 127.0.0.1:53: read udp 127.0.0.1:43266->127.0.0.1:53: i/o timeout'. Proceeding to next."
time="2020-05-24T06:27:57-07:00" level=info msg="Unable to update container /watchtower, err='Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on 127.0.0.1:53: read udp 127.0.0.1:37464->127.0.0.1:53: i/o timeout'. Proceeding to next."
time="2020-05-24T06:28:07-07:00" level=info msg="Unable to update container /zoneminder, err='Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on 127.0.0.1:53: read udp 127.0.0.1:52264->127.0.0.1:53: i/o timeout'. Proceeding to next."
time="2020-05-24T06:28:17-07:00" level=info msg="Unable to update container /nextclouddb, err='Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on 127.0.0.1:53: read udp 127.0.0.1:33567->127.0.0.1:53: i/o timeout'. Proceeding to next."
time="2020-05-24T06:28:27-07:00" level=info msg="Unable to update container /emby, err='Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on 127.0.0.1:53: read udp 127.0.0.1:36987->127.0.0.1:53: i/o timeout'. Proceeding to next."
time="2020-05-24T06:28:37-07:00" level=info msg="Unable to update container /jellyfin, err='Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on 127.0.0.1:53: read udp 127.0.0.1:41423->127.0.0.1:53: i/o timeout'. Proceeding to next."
time="2020-05-24T06:28:47-07:00" level=info msg="Unable to update container /letsencrypt, err='Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on 127.0.0.1:53: read udp 127.0.0.1:45718->127.0.0.1:53: i/o timeout'. Proceeding to next."
time="2020-05-24T06:28:57-07:00" level=info msg="Unable to update container /airsonic, err='Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on 127.0.0.1:53: read udp 127.0.0.1:55250->127.0.0.1:53: i/o timeout'. Proceeding to next."
time="2020-05-24T06:29:07-07:00" level=info msg="Unable to update container /portainer, err='Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on 127.0.0.1:53: read udp 127.0.0.1:45994->127.0.0.1:53: i/o timeout'. Proceeding to next."
time="2020-05-24T06:29:17-07:00" level=info msg="Unable to update container /nextcloud, err='Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on 127.0.0.1:53: read udp 127.0.0.1:59017->127.0.0.1:53: i/o timeout'. Proceeding to next."
time="2020-05-24T06:29:23-07:00" level=info msg="Unable to update container /duckdns, err='Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp 10.0.0.1:443: connect: network is unreachable'. Proceeding to next."
time="2020-05-24T06:29:23-07:00" level=info msg="Unable to update container /cloudcommander, err='Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp 10.0.0.1:443: connect: network is unreachable'. Proceeding to next."
time="2020-05-24T07:41:44-07:00" level=info msg="Waiting for running update to be finished..."
time="2020-05-24T09:42:19-07:00" level=info msg="First run: 2020-05-24 09:47:19 -0700 PDT"
Alles anzeigen
In Portainer's Container details section you can place --cleanup in the CMD box.
Your network errors look to be DNS related. Maybe the container has no access to DNS?
So if I understand correctly, when I create Appdata under shared folder, I still use absolute path when creating container. so I can't put anything in OS drive right?
You could use any path of your liking, even on the OS Drive. You should avoid it though, for reasons like filling up the OS Drive.
Greetings
David
That's helpful to know. You are Rockstar of this forum for beginner.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!