mrpops2ko

i've searched in the thread but can't really find it addressed too much but how do people go about mass updating their containers? i understand that the update stack button works and is great but its a bit cumbersome when you have to do that 30-40 times, rather than a single button press what solutions have people come to, to automate this? or is this something that could be added natively to the plugin? edit: seems watchtower is the solution that is posited in the previous page so i'll give that a shot

just checked it all again and seems to work now. so first i tried version: "3.9" services: tautulli: image: lscr.io/linuxserver/tautulli:latest container_name: tautulli env_file: - /boot/config/plugins/compose.manager/projects/test1/.env environment: - PUID=1000 - PGID=1000 - TZ=${TZ} ports: - 8181:8181 restart: unless-stopped networks: br0: ipv4_address: 192.168.1.133 volumes: - ${DOCKERDIR}/tautulli/config:/config networks: br0: external: true which results in WARN[0000] The "TZ" variable is not set. Defaulting to a blank string. WARN[0000] The "DOCKERDIR" variable is not set. Defaulting to a blank string. then i tried the same but env_file: - /boot/config/plugins/compose.manager/projects/.env which results in the same then i tried using .env: /boot/config/plugins/compose.manager/projects/.env [+] Running 1/1 ✔ Container tautulli Started 0.2s this worked without needing to declare the env_file. sorry about wasting your time, it seems to have always worked. Would it be possible to have a drop down menu or some kind of sticky location to the stack settings env file path? or maybe some kind of config file where we can store say multiple variables with an auto enabled: true / false flag?

take this one for example version: "3.9" services: tautulli: image: lscr.io/linuxserver/tautulli:latest container_name: tautulli env_file: - path: /boot/config/plugins/compose.manager/projects/.env service: tautulli environment: - PUID=1000 - PGID=1000 - TZ=${TZ} ports: - 8181:8181 restart: unless-stopped networks: br0: ipv4_address: 192.168.1.133 volumes: - ${DOCKERDIR}/tautulli/config:/config networks: br0: external: true you can delete the networking, its just using ipvlan but you can see we are declaring variables ${DOCKORDIR} and ${TZ} now define those values in your .env lets say TZ=UTC DOCKERDIR=/mnt/cache/appdata watch as you'll be unable to run, or rather when you run it you get an error stating that it cant find those variables so its defaulting to blank ones. This is because .env is special and will accept both environment variables and interpolate. declaring like above wont do that. if you wanted to get rid of the error you could on your docker host do `export DOCKERDIR="/mnt/cache/appdata"' but this would then store that in the unraid host which isn't desired. now if you just simply copy the .env from /boot/config/plugins/compose.manager/projects/.env and place it in /boot/config/plugins/compose.manager/projects/tautulli/.env (so it resides alongside the docker compose file) then everything will just work because of the things i mentioned.

there are effectively 2 options to have proper global .env support, its either have a file that sits at /boot/config/plugins/compose.manager/projects/.env and symlink it to each project folder, so for example /boot/config/plugins/compose.manager/projects/plex/.env would be a symlink of /boot/config/plugins/compose.manager/projects/.env or alternatively on every click of the docker up / docker down / stack update, it would take the values from /boot/config/plugins/compose.manager/projects/.env and append them to that specific projects .env file this would then allow for variable interpolation in the compose files, as most people desire

yes tested it just now and it doesn't work. its not the same. .env is special and env_file won't work, nor will -e flag it has to be in the same folder as the project

yeah unfortunately this implementation suffers with the exact same issues i mentioned previously in relation to interpolation. the only real solution to do global envs is to have one which sits outside and has a symlink to it in the project directory called .env the other solutions wont work. this is because docker has some special functions associated with .env rather than anything else, which allows it to pass interpolated variables as well as env variables.

thanks but can you elaborate more on this because i think it might not be exactly what i wanted now what i wanted was to put the envToUse in /boot/config/plugins/compose.manager/projects/envToUse and then that env file would subsequently be copied / replicated or symlinked to all the sub directories (i.e /boot/config/plugins/compose.manager/projects/plex/.env) the reason for this, is that the .env has special properties that otherwise addressing them via env_file declaring doesn't do. like my previous example with doing interpolation $DOCKORDIR your previous comment 'Is there a Github repo for this? I've modified some of this plugin locally to allow use of a "master" .env with multiple projects and I'd like to share it back.' seemed to hint at doing exactly this. if i declare an envToUse does it replicate across other projects?

hi im not sure if you are accepting feature requests but this would be useful for me. i've been down a rabbit hole of trying to do something like having a global .env file which i can use to do references and interpolation. it seems thats not possible if you have docker-compose files in directories and try to reference outside of it, even by hardcoding. i tried both env_file full/path and env_file ../.env and neither work. i'm wondering if we could have a global menu added and what that does, is upon boot, create, start and stop of any containers it will check the values in the global .env file and place them into each containers .env file. this would then allow easy referencing in compose, so for example instead of having to write out a long /mnt/ssd/cache/appdata/ you could reference that was $DOCKORDIR and just call $DOCKORDIR each time.

curious case post upgrading of parity drive never spinning down, appears to be some very small writing occuring and i cant out the cause of it

this 9+ year desired feature is still desired, nvme's have gotten so cheap now this would be a huge power up for our arrays.

it sounds like you are experiencing the same thing i am / did, if you check some of my posts i compare the speeds of SMB on windows server vs smb on unraid and its night and day different. In addition to that though, i've noticed what you have, as well as other things. For example when we had windows server installed, you could be at your windows desktop and just unzip from the remote desktop, as if it was locally stored on your hdd. with the linux implementation of smb, we cant do that. To get around that particular scenario I created a bash script to ssh into the unraid box, check what path i was on and find the file i wanted to unzip and execute 7z and then do perms cleanup and close. I imagine you'll need to do similarly and ssh into the other unraid and execute the move / copy that way. Others have done it via using midknight commander or that other docker one with rsync. Its unfortunately the nature of the beast and if you want that functionality we need windows server.

hahahah ok well thats a show stopper. i'm thinking though if its possible to execute scripts (does that work?) then we can fire off something something which starts a cron to invoke 'mover stop' after x period of time, and we use the maths to figure out how long it'd take to shift y amount of data (so in my case 1tb) my array performs on average 120 MB/s per drive. (assuming large sequential file transfer) (1 tb) / (120 (MB / s)) = 2.31 hours so i just need to do a daily mover, for 2 hours to shift like 800gb of data whenever its filled 85% and the script to stop it. that should in theory allow us to do it that way right?

Thank you, i don't quite understand how to perfect the settings to accomplish this. These are mine currently but forgive my lack of process understanding, wouldn't this mean that once my cache hits 50% utilisation it would immediately transfer ALL files that exceed 15 days and not cease transferring them until it satisfies the <14 days requirement? because that'll be a show stopper if so. Or does mover just instantly stop the moment I reach below 50%? because I tested this and had some strange observations, I hit the 50% and then now my cache is at 44%, so some files got transferred. I'm assuming it moves files down to the nearest neighbour % interval?

i'm assuming this isn't possible, since the options don't seem to exist but is it possible to configure mover to work based upon atime and set it to move around 10%? so anytime I hit (my cache is an 8tb nvme cache) 7tb used, it'll clear out 1tb of the least accessed content, onto spinning rust can i accomplish this and if so, how?