• Content Count

  • Joined

  • Last visited

Community Reputation

12 Good

About bling

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. closing out my own thread. TLDR, turned out it was one of my docker containers spinning up on a schedule to scan files. took a while to find it, but i think the effort was worth it. i got super annoyed so i used the brute force hammer method. i installed graylog and configured every container to send all logs there. also added all the system stuff like dmesg, syslog, etc. sooooo, yea, scratching this itch gave me centralized logging for everything 🙂
  2. does anyone know if there's a way to store files simultaneously on the cache drive and on the array? i'm trying to be a little more green so i'm trying to see if there are ways to minimize disk spin up. something along the lines of; file gets written to cache. mover copies to the array instead of moving it. after some time or free space threshold, files that were previously copied get deleted from the cache. applications would still look under /mnt/user, so as far as they're concerned, there's only one copy of the file, but the array will no
  3. take a look at /boot/config/plugins/dockerMan/templates-user, which is where unraid stores all the XML templates. any time you add a docker container from the community apps, for example, creates a file and saves it here. if you're using docker-compose you don't need to fill in the rest, just the high level things like the name, repository, icon, URL, etc. and of course, this is all non-standard and really the only reason why you would do this is if you want nice icons on your dashboard. you do not want to use unraid to manage your containers because it will mess up b
  4. not sure if it happened in 6.9.1 because i wasn't looking at it. i only stumbled upon this because it appears 6.9.x changed the default for spin down to "never", and when i noticed all my disks were always green i went ahead to changed it and that's when i observed that disks were up when they weren't supposed to. had a brief read of your linked thread but i don't think my issue is that. i don't have problems spinning down disks, that happens as expected. my problem is they randomly wake up and there's nothing in file activity logs or syslogs to indicate any read/write is happen
  5. if there's particular information from diagnostics you're specifically looking for i can provide that. but since i have verbose logging turned on everywhere i'd have to go through all the files to ensure it's appropriately anonymized.
  6. currently running 6.9.2 and observing disks spinning up when there's no reason to. i've tried tracking it down but no luck. the syslog pretty much always contains "emhttpd: read SMART /dev/sdb" when the disk spins up. i believe this is a red herring as unraid itself is not the one that actually spins up the disk, but will use smart to read the temperature after something else spins up the disk (please correct if wrong). i installed the File Activity plugin so there are cases where i observe "read SMART" without a corresponding entry to read/write anything.
  7. count me as another user who's migrated everything over the docker-compose so this is a welcome development. i've also found the missing icons annoying. rather than editing core files i'm opted to create templates instead with the same container name and leave everything else blank. this is enough to trick unraid. something like this: <?xml version="1.0"?> <Container version="2"> <Name>portainer</Name> <Repository>portainer/portainer-ce</Repository> <Registry></Registry&
  8. just upgraded. posting what i had to do for others in case they had similar issues to me. docker-compose all of my containers are in a single docker-compose.yml file and that reloaded without any problems after the array was started. hooray! ssh per the release notes, a password is required now. i enjoy the convenience of no password so i ended up just setting up private key authentication instead. and...that's it. pretty seamless upgrade. thank you!
  9. the image doesn't have any time zone info so you need to add a volume mount for /usr/share/zoneinfo
  10. feature request. can we add the ability to disable certain checks? for me, notably all of the checks for docker (updates, templates, etc) are creating false positives because i've completely swapped everything for docker-compose. however, even if i didn't do that, i'm sure there's a ton of people that would prefer checking for docker image updates to be disabled. "if it ain't broke, don't fix it". this is especially true when a new docker image introduces a breaking change, which could be especially bad if it corrupts the appdata and there are no backups.
  11. stumbled upon this bug report when i noticed the same thing today. when using private shares, any files written are owned by the logged in user, and not 'nobody', which can cause various annoyances later since so many things assume everything is owned by nobody. i fixed it by modifying the samba config, you can add the following to /boot/config/smb-extra.conf [global] force user = nobody force group = users
  12. you need to set the network type to 'none', so that the --net in the extra params will work. also, if your child container has a port exposed you need this defined on the parent container instead otherwise you can't access it.
  13. hit the 'add container' button at the bottom of the docker tab in unraid and fill in the details. as for privoxy, that's just a proxy that allows other applications to reuse the existing VPN connection of the container. prior to the introduction of --net, this was how you got other containers to reuse a single VPN connection. however, it also means that the software must support specifying a custom proxy server. with --net, you don't need to define a proxy configuration in any client running in a child container because it's network gets isolated to only use what the parent cont
  14. there are tons on docker hub. pick one and add it manually.
  15. instead of. using --net replaces any existing method for achieving this. you don't need to set up proxies or anything because any "child containers" will reuse the network of the parent. so all you need to do is find a docker container (there are tons) that do openvpn + a kill switch as the parent and you're good.