Beiträge von ryecoaaron

Don't edit files. Read all of these steps.

create a self signed cert in the omv web interface.

set that cert for the omv web interface

sudo omv-showkey sslcertificate

get the uuid for the cert you created

Then run my script https://github.com/ryecoaaron/scripts/blob/main/update_cert.sh

update_cert.sh b11bfa4e-11dc-4e49-a450-9fee0d786702 cert.pem privkey.pem letsencrypt

You can set this same command as a hook script to run every time the script is renewed and the web interface will use your cert. I use this will all of my omv systems except I am using acme.sh to get a wildcard cert.

Zitat von vfr-to-ifr

But despite our best efforts failures do sometimes occur and it would be optimal if the plugin possessed the defensive measure requested.

I am open to suggestions but it is harder than you think. For example... If someone unplugs a usb drive while it is mounted, many checks will think the drive is still mounted.

Zitat von AllesMeins

Or any other method that would keep multiple snapshots on the usb storage?

Beitrag

RE: Feature request: Rsnapshot plugin to bypass backup if the target folder is not mounted

Neither the rsnapshot plugin nor the borgbackup plugin are designed to use a disk that is not mounted all the time. I started working on a borgusb plugin that was similar to the usbbackup plugin but used borg but never got far in it.

You could use rsnapshot to backup to another location on your server. Then use the usbbackup plugin to sync that rsnapshot backup to the usb disk. I know it is additional space but extra backups are never bad.

ryecoaaron

26. Juni 2025

good to hear.

Zitat von BebeMischa

But, how can it be suddenly wrong? It was fine all the time...

It looks like you used autocompose almost 3 years ago to create this compose file. Docker compose does change over time with updates. This was not caused by the plugin.

remove this line:
org.opencontainers.image.created: 2022-10-28T23:26:40-05:00

I would actually remove a lot more lines but you probably don't have to. These are the lines I would get rid of:

ipc: private
labels:
com.docker.compose.config-hash: 6a29f80c20ec7f4a9113627ba6cacc22756aa2d29cb31174ea2f23f02bb57afb
com.docker.compose.container-number: 1
com.docker.compose.depends_on: ""
com.docker.compose.oneoff: False
com.docker.compose.project: jelly
com.docker.compose.project.config_files: /data/compose/10/docker-compose.yml
com.docker.compose.project.working_dir: /data/compose/10
com.docker.compose.service: jellyfin
maintainer: thelamer
org.opencontainers.image.authors: linuxserver.io
org.opencontainers.image.created: 2022-10-28T23:26:40-05:00
org.opencontainers.image.description: "[Jellyfin](https://jellyfin.github.io/)\
\ is a Free Software Media System that puts you in control of managing and\
\ streaming your media. It is an alternative to the proprietary Emby and Plex,\
\ to provide media from a dedicated server to end-user devices via multiple\
\ apps. Jellyfin is descended from Emby's 3.5.2 release and ported to the\
\ .NET Core framework to enable full cross-platform support. There are no\
\ strings attached, no premium licenses or features, and no hidden agendas:\
\ just a team who want to build something better and work together to achieve\
\ it."
org.opencontainers.image.documentation: https://docs.linuxserver.io/images/docker-jellyfin
org.opencontainers.image.licenses: GPL-3.0-only
org.opencontainers.image.ref.name: 2ff50259c5f6f0fed29e8074a36973275512beae
org.opencontainers.image.revision: 2ff50259c5f6f0fed29e8074a36973275512beae
org.opencontainers.image.source: https://github.com/linuxserver/docker-jellyfin
org.opencontainers.image.title: Jellyfin
org.opencontainers.image.url: https://github.com/linuxserver/docker-jellyfin/packages
org.opencontainers.image.vendor: linuxserver.io
logging:
driver: json-file
options: {}

Neither the rsnapshot plugin nor the borgbackup plugin are designed to use a disk that is not mounted all the time. I started working on a borgusb plugin that was similar to the usbbackup plugin but used borg but never got far in it.

You could use rsnapshot to backup to another location on your server. Then use the usbbackup plugin to sync that rsnapshot backup to the usb disk. I know it is additional space but extra backups are never bad.

Something is wrong with your compose file it seems. Post the compose file.

Zitat von bitrotkilla

'm not using qcow2 but instead using raw (conf). Perhaps I should just do a backup from Proxmox itself.

raw shouldn't be a problem. Backing up from proxmox is much easier.

Zitat von andrzejls

found that it grew from 4.27 to 4.33GB. That is a quite a jump

60mb is a big jump? Probably just apt cache. apt-get clean or apt clean button in omv-extras will clear it.

Zitat von andrzejls

so what was remaining ~ 43GB on the original drive?. Is there a way to "clean-up" OMV system drive?

probably logs and docker images. You would have to look at the drive to know.

I have an OMV system that has been upgraded since OMV 4 and it is using 4.6G after all these years.

All SSDs are limited writes. But I am guessing the qcow2 file is corrupt. Not sure what else it could be.

Thanks for the help.

I don't recommend users manually change their system. I think we can get this change out fast enough.

I put 7.6.10 in the repo about an hour ago.

Zitat von Mic2024

Will you implement the fix described here on GitHub or do I need to do it as a workaround on my system? I would prefer to get it implemented in an official update. If I need to do it manually which file on my system, do I have to edit?

When I push to github, that means it will be in the next release. And since there is nothing remotely dangerous about either of these issues, it is safe to wait for the release (probably in the next day).

Zitat von Mic2024

Ans also due to any reason it seems when you make an update of a container available for download (by pulling it again) you get a second entry in the Images list.

Looking more at this, your screenshot is correct. If you pull a new image and restart your container to use it, you should see what your screenshot shows. You will see the latest image which your container is using and the old image that your container was using. Until your prune the images, the Images tab should show both. This tells you that you have images taking up space on your system and that they can be pruned since they are not in use.

My system before prune

After prune

This change should fix the locally built image status showing failed.

try to return NA for locally built images that won't have any none or… · OpenMediaVault-Plugin-Developers/openmediavault-compose@28beb04

… empty digest Signed-off-by: Aaron Murray <plugins@omv-extras.org>

github.com

If you could post the output of this command, it might be helpful?

sudo docker image ls --all --digests --no-trunc --format "json"

That is a smart error. There no way you wrote an exabyte to a 16gb msata disk. The write speed is too slow to write that much in decades.

Hard to say if it is failing though. If the system is important, I would replace it. Otherwise, use omv-regen to create a backup. Just about any other backup method will clone bad sectors and/or corrupt files.

good to hear.

Zitat von Mic2024

there have been updates for the Docker Compose Plugin in OMV7 and there is a small bug in the tab Images in the WebGUI. For self-build containers (defined in the tab Dockerfiles) the status is set to failed now. This is confusing. In the past I could read there just n/a which was a better information.

This status column and deduplication of the image list is a real pain. I will look at it but I think it is obvious that the plugin won't be able to get a status for a self-built image.

Zitat von Mic2024

Ans also due to any reason it seems when you make an update of a container available for download (by pulling it again) you get a second entry in the Images list.

The newly pulled image has a different digest and isn't showing a tag. The code that deduplicates the image list thinks the image is a different tag. Just try to remember the plugin is using the output of docker image. So, this isn't a bug. It just is different than before for humans. I will see what I can do but not promising anything. I assume clicking the clear cache button on the Settings tab doesn't fix it?

Is sdh a disk that has limited writes? I have seen writes kill a usb stick in 2 days.

Never used crowdsec.