Posts by cubemin

As a workaround, you could also direct Emby to disallow deleting media for any given user (Emby user, not OMV user).

Anyway, do you back up your media on a schedule? Simply restoring a deleted file from the backup would do it, too...

That did it. Performed an apt clean repos, then installed the plugin without a hitch.

Thank you for replying faster than I ever dared hope!

So this just happened...

Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LC_ALL=C.UTF-8; export LANGUAGE=; export DEBIAN_FRONTEND=noninteractive; apt-get --yes --allow-downgrades --allow-change-held-packages --fix-missing --allow-unauthenticated --reinstall install 'openmediavault-mounteditor' 2>&1' with exit code '100': Reading package lists...

Building dependency tree...

Reading state information...

E: Unable to locate package openmediavault-mounteditor

OMV\ExecException: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LC_ALL=C.UTF-8; export LANGUAGE=; export DEBIAN_FRONTEND=noninteractive; apt-get --yes --allow-downgrades --allow-change-held-packages --fix-missing --allow-unauthenticated --reinstall install 'openmediavault-mounteditor' 2>&1' with exit code '100': Reading package lists...

Building dependency tree...

Reading state information...

E: Unable to locate package openmediavault-mounteditor in /usr/share/openmediavault/engined/rpc/pluginmgmt.inc:250
Stack trace:
#0 /usr/share/php/openmediavault/rpc/serviceabstract.inc(646): Engined\Rpc\PluginMgmt->{closure:Engined\Rpc\PluginMgmt::install():231}()
#1 /usr/share/openmediavault/engined/rpc/pluginmgmt.inc(231): OMV\Rpc\ServiceAbstract->execBgProc()
#2 [internal function]: Engined\Rpc\PluginMgmt->install()
#3 /usr/share/php/openmediavault/rpc/serviceabstract.inc(124): call_user_func_array()
#4 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod()
#5 /usr/sbin/omv-engined(546): OMV\Rpc\Rpc::call()
#6 {main}

...as I was attempting to install openmediavault-mounteditor 8.0 from the plugins list. Is the AMD64 version somehow missing from the repository?

I installed it on my ARM64-based backup OMV system just fine, but on my Intel NAS, no dice.

ryecoaaron help, please!

I would suggest exposing each /srv/dev-disk-by-uuid-... as a Samba share, if you don't want to share each subfolder individually.

But you should not expose /srv itself as a share, so you won't have to see the ftp, salt, pillar folders and won't risk damaging them by accident.

Good idea. Just ordered one, SATA cables included. Thanks 🙂

I'm planning a major upgrade of my storage, moving from a 3x8TB RAID 5 to a brandnew 5x12TB RAID 6 array.

The idea is to connect all 8 disks, create the new RAID 6 array in OMV while the existing RAID 5 remains in use, and rsync all of my data to the new array. Then shut down all Docker containers, KVM guests, BorgBackup and other scheduled jobs, etc. and point all shared folders and such to the new RAID 6. (I would then run another rsync to capture any changes so as to ensure data integrity before re-starting any services).

The problem is that my motherboard only has 6 SATA ports (though I actually could power all 8 drives from the PSU). So I'm considering connecting 2 of the 3 RAID 5 disks via an external USB 3.0 dual docking station, and leaving the third one connected internally. This would only be on a temporary basis until the RAID 6 is up and running, and I can remove the old disks completely.

The question is if this would work OK. Would mdadm mount the RAID 5 array without problems if 1 disk is on SATA and 2 disks are on USB? Or should I expect issues? If so, would I have to use mdadm from the commandline to get it to assemble the array manually?

Quote from verstehnix

Spinning down the HDD with OMV8's smartmontools only works when setting the spindown-time less or equal 20 minutes.

That reminds me of when I first had trouble getting my disks to spin down even with hd-idle. You wouldn't happen to have active SMART monitoring enabled on a 20-minute schedule, would you?

On my backup server (where disks only spin up once a day for a daily backup from the main server), I had to ensure that SMART monitoring is set to a greater time period than hd-idle, so the hd-idle timer wouldn't be "reset" by each SMART check before it was time to spin down the drives. That might do the trick here as well.

Does anyone have any insight on this?

That flashmemory plugin is meant for OMV systems that run off a USB stick or SD card, or similar flash-based storage (other than SSD drives) that doesn't have wear leveling. The plugin helps to prevent premature failure of such storage.

You can simply uninstall that plugin with no adverse effects if you wish; your SSD should be fine without it. Or you can configure it to your needs.

Installing OMV-Extras really doesn't add any complexity or overkill to your system - it just provides Docker functionality (completely optional and must be explicitly enabled before it's available) and a host of plugins you can install one by one as needed.

One of these plugins is the mount editor, which allows you to remove the quota options from your /etc/fstab entries. It sounds like you're saying that you already went that route...?

If you really wanted to do it the manual way, editing /etc/fstab directly wouldn't do it because OMV would just overwrite it at some point. You'd have to edit /etc/openmediavault/config.xml instead and look for an entry that looks like this:

      <mntent>
        <uuid>bcaf3081-d5c9-4607-af5b-222bc46422e8</uuid>
        <fsname>/dev/disk/by-uuid/########-####-####-####-############</fsname>
        <dir>/srv/dev-disk-by-uuid-########-####-####-####-############</dir>
        <type>ext4</type>
        <opts>defaults,nofail,user_xattr,acl</opts>
        <freq>0</freq>
        <passno>2</passno>
        <hidden>0</hidden>
        <usagewarnthreshold>90</usagewarnthreshold>
        <comment/>

There's one block like this for each storage device known to OMV. You can tell that the <opts>defaults,nofail,user_xattr,acl</opts> is the one to edit. After that, you'd have to either run an omv-salt command - I'm not sure exactly how - or just reboot the server for the change to become active.

I do not recommend this approach unless you're absolutely comfortable editing what could be called OMV's "registry" (like the Windows registry). If you inadvertently change something else by accident, the whole system can crash and burn.

StreetBall - no, one is ARM-based. My main NAS runs on Intel x86 hardware.

macom - thanks for the link (I was aware of it). As of a few moments ago, the Armbian apt update error is gone and all is back to normal.

Google seems to think that your Humax PVR only supports the (insecure) SMB1 protocol for folder sharing via Samba, which isn't enabled in either OMV or Windows 10/11 but can be turned on. Have you looked into that?

I previously customized the default scrubbing schedule set up by OMV by editing /etc/cron.d/mdadm like so:

# edited this to run at 11:41pm every 2nd month on the first friday thanks to https://cron.help

41 23 * */2 5 root if [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi

Today is Saturday, 1/10/26, and a RAID scrub started this afternoon around 3:30pm, I think. This was unexpected - then I noticed that mdadm was changed to mdadm.dpkg-bak at some point.

I wonder if some other mechanism to schedule the scrub has replaced this cron.d file, but I can't quite track down what or where it is. I'd like to continue to use my custom schedule from above. What is the proper way to do this?

I found my answer. It's a stable point release to Debian 13.3 releasing today.

The Armbian issue, I suspect, will eventually be fixed by the Armbian team, so I will wait and see.

This morning, all of a sudden, I have several dozen pending updates on my two OMV servers - not for OMV itself, but for the underlying OS.

Main server running on Debian (amd64) shows 70 updates ready to install.

Backup server running on Armbian shows 34 updates... but at the same time, the system sent me an email stating:

Quote

/etc/cron.daily/openmediavault-apticron:

E: The repository 'http://apt.armbian.com trixie Release' is no longer signed

I'm suspicious of this. Is anyone else seeing a massive wave of pending updates this morning?

Well, in the first docker-compose you posted, there was a slash after "MainPool" and before the colon. It seems you caught and fixed that while putting your paths in apostrophes.

I'm not sure that using relative, rather than absolute, paths to define your volumes is a good idea - I could be wrong, as I've never tried that.

Are you assigning ./data and ./config.yaml to the same container path? Why?

The device doesn't have standard support from Armbian, but it's still community-supported. A Debian 13 minimal/IOT image showed up just today - that's the one to use for a fresh OMV install.

I'm curious - what's an ABI?

Omigosh, thank you.

I just upgraded to 8.0.2 and had this exact same problem - couldn't figure out the cause. Phew!

Quote from ryecoaaron

For every command?

Yes.

To be clear, that's borg on the server side (their end), not the local borg in OMV. I linked to the support page explaining this in my first post.