nraygun

Per a Discord and Reddit post, it appears a patch for this is in the works.

I have MaxMind setup for geoIP info but it doesn't seem to be updating its database weekly. In the container I see in /etc/crontabs/root a single line that appears to update certificate as follows 8 2 * * * /app/le-renew.sh >> /config/log/letsencrypt/letsencrypt.log 2>&1 The line above also shows if I do a crontab -l in the console. Do I need to edit this file to include the line from /config/crontabs/root that runs the weekly update of the database? Or maybe I need to replace the whole existing /etc/crontabs/root with the file that's in /config/crontabs/root so it catches all of the other periodic jobs. 0 3 * * 6 run-parts /etc/periodic/weekly Or do the scripts in /config/crontabs get processed somewhere else?

Assuming there's nothing wrong here.

FWIW, I found this method in Reddit that seemed to work for me until they fix the log bug. But note if you have qbittorrent internet facing, it's a risk. Add this line under [Preferences] in the config file, to set the default password manually to: adminadmin WebUI\Password_PBKDF2="@ByteArray(ARQ77eY1NUZaQsuDHbIMCA==:0WMRkYTUWVT9wVvdDtHAjU9b3b7uB8NR1Gur2hmQCvCDpm39Q+PsJRJPaCU51dEiz+dTzh8qbPsL8WkFljQYFQ==)"

Ugh. Until they get this bug fixed, can I just revert back to 4.6.0-1-01? If so, does that version use libtorrentv1?

Howdy! The container update overnight causes this to show up in the log after every successful IP update: "Detecting IPv4 via DuckDNS". So I get: Your IP was updated at Sat Oct 28 06:29:03 CDT 2023 Detecting IPv4 via DuckDNS Your IP was updated at Sat Oct 28 06:31:20 CDT 2023 Detecting IPv4 via DuckDNS Your IP was updated at Sat Oct 28 06:36:32 CDT 2023 Detecting IPv4 via DuckDNS etc. Is this anything to be concerned with?

Thanks! The revisions are the same. In fact, just about everything about the drives are the same. I guess it's just platter quality on this particular drive as you said.

Bingo! This is the way! Thank you very much @SimonF!!! My container is back down to 42% after deleting all of the old orphaned images that were in there. And none of the stopped containers were affected. I guess I'll add this to the list of things to do when I update a container: Update it via a specific tag, check the .conf files, remove old images.

I think I want to use: docker image prune -a The dox say this: To remove all images which are not used by existing containers, use the -a flag So the stopped containers are using images so these images and containers shouldn't get deleted. But I think it should delete all the extra images that are taking up space that are not in use by a container. Can someone confirm my understanding?

I took a risk and issued a "docker rmi <containerid>" on one of the containers that is not in my Docker list. It deleted it along with a bunch of sha256 entries. But the image shrank! I'm onto something, but need to know if I just should do this with the other containers that are in there that seem to be taking up space.

I did an update to a container and got a warning that my Docker image was 72%. I see this in the Memory area on the left on the main page too. I Googled here and there and found a command that lists Image Space Usage: docker system df -v It shows some old containers I don't use any more that are not in the Docker list. It also shows multiple older images for Nextcloud. Probably from upgrading it. For example, here's a bunch of prior versions of Nextcloud that I think are in the image: REPOSITORY TAG IMAGE ID CREATED SIZE SHARED SIZE UNIQUE SIZE CONTAINERS linuxserver/nextcloud 27.1.0-ls271 844b0424c706 5 days ago 881.8MB 25.43MB 856.4MB 1 linuxserver/nextcloud 27.0.2-ls269 2c40df37dcb4 2 weeks ago 828.4MB 0B 828.4MB 0 linuxserver/nextcloud 27.0.2-ls267 88802f11c09b 4 weeks ago 828.4MB 25.43MB 803MB 0 linuxserver/nextcloud 27.0.2-ls266 4994a0316a3d 5 weeks ago 828.4MB 25.43MB 803MB 0 linuxserver/nextcloud 27.0.1-ls261 2832124f79ad 7 weeks ago 825.9MB 0B 825.9MB 0 linuxserver/nextcloud 27.0.1-ls260 0d0af4c9e41a 8 weeks ago 831.1MB 0B 831.1MB 0 linuxserver/nextcloud 27.0.0-ls255 4e1044e331d0 2 months ago 822.7MB 0B 822.7MB 0 linuxserver/nextcloud 27.0.0-ls252 09e7ddf65bd8 2 months ago 822.7MB 25.42MB 797.3MB 0 There's another one in there that is not in my current Docker tab list so I think it's just eating up space. I don't want to do a prune because I think the prune would delete stopped containers, right? Container size: Total size 13.1 GB 1 GB 66.3 MB Docker volume info: Total devices 1 FS bytes used 20.58GiB devid 1 size 30.00GiB used 22.52GiB path /dev/loop2 What's the guidance here? Do I just go in and delete these old containers?

Just discovered this plugin - great job! Am I reading this right in that disk 2 (green) is a little on the wonky side because of how much it deviates from the other 2 disks? Disks 1-3 were all shucked at the same time. sdc is an unassigned older drive for backups.

Thanks @iXNyNe! If you have yours setup to update to the latest tag, how do you handle the updates to the .conf files? I think the updates add new .sample files, and if there are any changes to the .conf files for your configuration, I think you'd have to merge in any changes from the new .sample files.

I know the overall best practice for maintaining the container is to pin a specific tagged version, but what is the best practice for when to change the tagged version of the Nextcloud and MariaDB containers? On a major release, on a point release, etc.?

Thanks. I was able to get beta firmware for my router which solved the problem of not being able to add more IPs to the firewall rules.

I guess this is normal per this thread:

This error has stopped. Not sure why. I guess it's OK. If anyone know anything further about this error, please let me know.

Any ideas on the iptables issue?

I see this in the syslog "exit status 1 from user root /usr/local/sbin/mover". I tried enabling logging and running mover again and it just says start/finished with no issue. Is exit status 1 normal for mover?

I tried the commands in that comment. No go. I then updated the version of the container to ls255. Still no go. I then deleted the files manually. Seems like it took a bit for Nextcloud to detect the files were gone. But I think I got it. Thanks!!! I kind of expected this to be fixed in a new release. Maybe that's still in process.

Went ahead and changed the ownership of the appdata for Nextcloud and it seems to have worked! The error went away in the "Security & setup warnings" area. Yay! Thank you! Now I just need to wait for the other fixes to the container for the invalid files thing.

Yikes. I'm a little cautious of running something with a -R option. (plus, I think you meant nextcloud not nextclouod) I've never had to do this before. But then again, I was updating Nextcloud manually at the command prompt before they included updates in the container. Before I do such things, has something changed with the container where I have to do this?

PUID = 99 PGID = 100 Should the PGID be 1000? I haven't touched these settings since I first setup the container years ago.

Yep, still got it. In addition, I see this in the logs. Not sure if it's related: Console has to be executed with the user that owns the file config/config.php Current user id: 99 Owner id of config.php: 1000 Console has to be executed with the user that owns the file config/config.php Current user id: 99 Owner id of config.php: 1000

Thanks @iXNyNe. The newly created crontab directory contains a single file called root that is exactly the same as the old one. Any other ideas?