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?
Absolute path
-
- OMV 5.x
- Nefertiti
-
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.
-
You do not want to use any /sharedfolders/.......host paths (what you are calling relative paths) in any docker volume or bind mounts.
-
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.
-
Thank you! Finally everything seems to work with absolute paths with the good sd my only remaining issue is watchtower I am not sure how to port this one
to OMV5
-
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.
-
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.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
