Posts by UKenGB

While working through how I was going to use Rescuezilla and GParted, I noticed that in /srv there was a couple of bare folders, whose disk no longer existed and one of them contained a 75 GB Time Machine sparse bundle from when I was trying to use this server for TM backups. Unable to make it work for more than a few days at a time I cancelled that idea, but unbeknownst to me, my wife's Mac had still been backing up and as there was no disk mounted there, it happily created the backup in the exposed folder, on the main system drive which then nearly filled up.

Having removed that, I am now using a more acceptable 28 GB and so no need to change the main drive.

I could regain another 10GB or so by relocating Podman and Docker data but no rush to do that as I've got plenty of headroom now - as I had originally planned when building this server.

Thanks, yes realised that rather obvious point after I posted my last question, so I was going to delete it, but you beat me to it.

I'll be getting Clonezilla set up and clone the drive onto the new one.

--

Actually I think I'll try Rescuezilla.

That why I chose a 120 GB drive in the first place as I thought that would be plenty, but it's now over 90% full and I keep getting warnings (as I set it to warn me above 85%).

Separating the raw OS from everything else that is eating up the space would be ideal but undoubtedly more problematic than simply installing a bigger drive.

I'll look into Clonezilla, but what does it do that rsync cannot?

I have now obtained a larger drive to use for the main system. So that'll allow a lot more breathing space and I can perhaps keep an eye on things and see if it's filling up and track down where.

However, what would be the best way to 'clone' the main system/boot drive to the new drive?

Currently it's a 120 GB M.2 NVMe and I want to replace that with the new 512 GB version which I have placed in an M.2/USB enclosure so I can simply connect it to the OMV server and then…?

My first thought would be to rsync the old drive to the new one and then physically swap the M.2 sticks, i.e. replace the original one (on the motherboard) with the new clone. However something tells me that wouldn't be all that's required. Are there any tricks required to make that new clone a bootable OMV system and what would they be? Or would it really be as simple as inserting the new clone onto the m/board and booting?

I seem to be running out of System storage space.

I built this machine with a 120GB NVMe system drive as OMV is not supposed to use much and at first it was fine. However, running PlexMediaServer and now Music Assistant and I find it is now 90% full which is not ideal, but both those applications combined still only use about 20 GB so should be 100 left and that should be more than enough to run OMV. Where's the space gone?

I used du to try and find big stuff, but it looks more like there's a lot of medium sized stuff taking up the space.

I've found a lot of old journald logs and trimmed those down to save over 2 GB, but that's not enough.

Are there any other logs/caches that would simply grow and eat up the space? Any other suggestions that avoid having to buy a larger drive and then migrate to that which won't be fun.

One of my data drives was having a problem, so got that sorted and everything has been behaving itself since, although don't really see the connection between drive errors and the issues I was having.

I also note that a recent OMV upgrade included a fix for compose/podman to make 'restart: always' actually work - which it now does. So that was nothing to do with my system.

On further investigation I discovered that Plex's database was corrupt. It looked ok in SQLite3 but Plex didn't like it.

I reverted to the most recent backup and PlexMediaServer started up no problem and has been running fine since.

Quote from ryecoaaron

dbus is down but I couldn't tell you why other than probably systemd didn't start it.

Ah, but it's not. First thing I checked, but dbus is actually still running.

I was able to restart it with reboot -f -f and now it's back up and able to execute systemd commands, updates and other config changes.

However this is how it seems to occur. After it starts, all works ok for a while but eventually that system scope bus error reoccurs and I think that means no more update notifications.

So directly after booting, it all works, but then eventually something will fail. Any idea what it can be?

This is an Intel i9 tower with large HD storage capacity (built specifically as my media server) and boots from an NVMe drive mounted directly on the motherboard. It's the same age as the motherboard (about 5 years) and shows no other signs of having a hardware problem.

I agree though that the system must be in a bad state. Systemd fails for everything with the above error. I cannot even shut it down or restart without that error, but I don't want to simply pull the plug.

Any clues as to what might cause this system scope bus error?

I'm running Music Assistant from a docker compose file they provide (modified to suit my environment) and has been running fine for a few months and I've updated it a couple of times.

Although using the docker compose file, in the Compose settings I selected to use Podman and although I'm not entirely sure what difference that makes. I do understand the difference between Docker and Podman, but in the case of running in OMV, I'm not sure what fits where.

Anyway, in the compose file I specified restart: always  so it always starts on boot. Except it doesn't.

In trying to figure out why, I tried some systemctl status … commands and just get this:-

Failed to connect to system scope bus via local transport: Connection refused

I have seen this before, since updating to v8 (now(8.2.2-1) and I was unable to make it reboot or shutdown due to that. In the end I had to kill the power, but since it restarted (spent some time I think disc checking) it has been running fine, with all the updates installing without error and as I said, Music Assistant (and everything else) runs fine - except if I do reboot (which is not often), MA does not automatically start and I have to run 'Up' in Compose.

It's not a big effort I agree, but several servers are co-dependent and if MA is not up and running then other servers have problems, so I'd like to ensure the MA container does reliably start after (re)booting.

Then there's the system scope bus issue.

A common cause of this is that d-bus is not running, but it is and AFAICT all is as it should be. So what is the above error message all about and is it connected with the MA container not starting at boot?

Could be completely unconnected, but I could do with some advice here to help track down what may be 2 problems.

I've been running Plex on my OMV server for many years, probably from OMV 4. It's not using Docker and has always worked perfectly so I saw no need to complicate things with Docker.

I've now been running OMV 8 for a while and had occasion to check Plex after I had to reboot the OMVserver after a brief power outage. I also took the opportunity to update Plex's repositories as they are currently requesting and simply ran the supplied all-in-one commend. This completed without error, but I cannot get Plex to start.

To be clear, I have not even attempted to look at Plex since well before the OMV 8 upgrade as there is a problem with the TV input that needs fixing and I've had no other use for it. So basically, I cannot say when it was last actually running.

I know the push is to use Docker, but this was a fully functional install and I've no doubt the entire (rather complex) configuration would be lost if I tried to switch to Docker which in any case, I do not want to do. It adds another layer of complexity that I'd prefer to not have to deal with and as I said, ran for years on this OMVserver without issue.

Is there some inherent reason why it is now impossible to run Plex on OMV without using Docker? I cannot see why that would be so I really don't want the bother of trying to move it all.

However, it won't start. Running systemctl start plexmediaserver does nothing and status shows:-

× plexmediaserver.service - Plex Media Server
     Loaded: loaded (/usr/lib/systemd/system/plexmediaserver.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/plexmediaserver.service.d
             └─override.conf
     Active: failed (Result: exit-code) since Wed 2026-03-18 16:11:16 GMT; 36s ago
   Duration: 108ms
 Invocation: 7583f547c45342519e3d9ecaf9839142
    Process: 23393 ExecStartPre=/bin/sh -c /usr/bin/test -d "${PLEX_MEDIA_SERVER_APPLICATION_SUPPORT_DIR}" || /bin/mkdi>
    Process: 23395 ExecStart=/bin/sh -c  export PLEX_MEDIA_SERVER_INFO_VENDOR="$(grep ^NAME= /etc/os-release | awk -F= >
   Main PID: 23395 (code=exited, status=255/EXCEPTION)

Mar 18 16:11:16 omvserve systemd[1]: plexmediaserver.service: Scheduled restart job, restart counter is at 3.
Mar 18 16:11:16 omvserve systemd[1]: plexmediaserver.service: Start request repeated too quickly.
Mar 18 16:11:16 omvserve systemd[1]: plexmediaserver.service: Failed with result 'exit-code'.
Mar 18 16:11:16 omvserve systemd[1]: Failed to start plexmediaserver.service - Plex Media Server.

That should be the latest release as updated by Plex's script and as listed by 'apt show'.

Anyone suggest how to get this running again?

Well I have to say, that was almost too simple.

Upgrading from OMV 7 to 8 simply ran without any problems, but now I'm searching through it trying to find what went wrong that I didn't catch. Not found anything yet.

It was indeed surprising to me as from 6 to 7 was something of a nightmare, so this was a very pleasant surprise.

I know it's so annoying when you're having terrible problems and others are smugly saying "all works great for me" and I'm normally in the former group, but very happy to be in the latter group this time. Well done to those who put together this upgrade.

To clarify, Time Machine operates differently when backing up to a network share compared to local storage. In the former case it places everything in a sparsebundle disk image, but in the latter it uses regular files and folders, so moving a drive between those 2 'connections' simply would not work.

The actual disk format of any network storage is transparent to the 'client'. So whether OMV storage uses ext4, XFS, etc makes no difference. TM is simply operating over SMB and knows nothing about the disk format used for that storage. However, that can affect how the files might be treated which is why TM uses a sparsebundle in those situations as that 'disk image' can be created as an APFS volume which TM knows how to deal with and make use of features it requires such as snapshots or hard linking directories, while being abstracted from the actual disk format of the storage and even the network protocol to a certain extent.

TM's sparsebundle is a lot of relatively small files for which ext4 is ideally suited and seems to be the recommended format for TM storage on a network share.

This concerns my OMV server which is a tower PC powered by Intel i9 with 32 GB RAM, 6 x 3.5" HDs, 2 x 2.5" HDs and boots OMV 7.7.17-1 (Sandworm) from a 120 GB NVMe M.2 (with 90 GB still free).

Having updated from OMV 6 -> 7, I duplicated a data disk in order to replace the source with the destination. All this was completed and the OMV server then ran for several days without issue.

I then added the second 2.5" HD, a brand new Seagate 2TB (to use for Time Machine backups from several Macs), added an ext4 filesystem on this disk and was first surprised by that being such a slow process, writing lots of inode numbers on the screen. Most of my disks use XFS filesystems which are created almost instantaneously and I don't recall ext4 creation creating all this output or taking so long.

Anyway, I set it up as a shared folder and configured it for SMB - with Time Machine support.

On a Mac, in TM settings, I was able to select that OMV share and started the backup. All looked good.

Until it failed part way through, complaining "The backup disk image could not be created."

On the OMV server, that disk was now for some reason effectively read only, even though not displayed as such anywhere. I was able to enter the TM folder and ls showed the list of files and folders, but I could not create anything in CLI. Trying to create a file or folder just resulted in an error about it being read only.

Now it gets weirder.

The other 2.5" HD was in an even worse state. When trying to simply ls, it took ages to finally produce the error ls: reading directory 'OMB/': Input/output error

That disc (called OMB) has been in use for a couple of years, used for OMV system backups, no problem. Now after an attempt to use a completely different HD as a TM backup target, that fails, leaves its drive unwritable and this one also apparently completely borked.

I futzed around with both these drives for some time, but was unable to get anywhere with them, both seemingly completely failed. Actually I unmounted OMB (the OMV backup HD, not shared in any way), but was then unable to remount it as OMV couldn't see it and mounting from the CLI failed, saying it couldn't be found.

As a last resort, I rebooted the OMV server and once restarted, both HDs were magically available again with no apparent problems. I restarted the TM backup on the Mac and it completed without error.

That was yesterday. Today, I ran the TM backup again on the Mac. It got part way through and failed again for exactly the same reason as yesterday. Checking on the OMV server and in the GUI, the OMV backup disk (OMD) appears ok, but the TM target disc is now 'Missing'. In the CLI, trying to use ls on OMD produces the same 'Input/output' error as yesterday.

I'm speculating that I can now do nothing with these disks until I reboot the OMV server.

So I'm rather wondering what on earth is going on. Not only is trying to perform a Time Machine backup to a TM enabled OMV SMB share causing that disk to bork, but it is also borking another HD whose only connection is they are both 2.5" and reside in the same dual HD bay, but with separate connections to different SATA ports, as far as the OS is concerned, they are not connected in any way. Oh, also they're both ext4, although so is the boot drive so doubt that's the cause of anything and neither are even half full. There's plenty of space on everything.

Can both these 2.5" HDs have failed simultaneously? Unlikely and twice now, the OMB failure (while doing nothing) is coincident with the TM backup failure and both apparently ok after a reboot, which rather suggests it's not a hardware problem.

Sorry it's a bit long, but just trying to explain it all.

Anyone shed any light on what's going on here?

Ha, ok so we're both oldies with similar ages of experience.

I agree docs should be written for noobs to understand and I accept that was not aimed at me.

I'll say again, I am truly appreciative of the work you do. OMV is fantastic and enormously useful. So kudos to you both.

Doesn't mean it won't frustrate me occasionally though.

Making some changes to my OMV config after upgrading to v7 and noticed the mergerfs volumes shown in Storage/File Systems had Labels but no Tags.

I have come across some discussion about the use of Labels with the consensus from OMV cognoscenti being that Labels are superfluous as OMV uses UUID.

Despite that, I like Labels, but also like to use Tags so I can easily identify a volume at a glance. I realise neither are relevant to system identification for mounting etc, but it helps visually and as I said, OMV itself displays Labels of mergerfs volumes (created presumably from the mergerfs Name).

However, when I selected one of the mergerfs filesystems and tried to edit it in order to add a Tag, the Edit icon is disabled/greyed out. I then clicked the inverted triangle (Show details) icon and was greeted with a big red error announcing it is not a device. True, it's not, but…

Made me wonder why the GUI allows you to click an icon/button that simply shows a big error, yet disables the Edit button that would allow you to set a Tag - which incidentally is perfectly possible by editing its mntent entry in config.xml.

So the advice is to not use Labels, but in the GUI, mergerfs volumes show Labels and Tags cannot be added which is somewhat mixed up.

I have actually achieved all I needed, but seems to me it would be better if for non device filesystems the 'Show details' button was DISABLED and the Edit button ENABLED so the user IS allowed to edit that filesystem entry to add a tag there rather than having to edit config.xml.

Just a suggestion.

Thanks for qualifying me as a noob when I was dealing with Unix possibly before you were born, but I'm not a mind reader and cannot second guess what a 'developer' meant or intended. Terminology is often inconsistent and e.g. 'cloning' actually means making an identical copy. It does not specify the means of doing that and in fact is often used in the context of computer drives to describe the process of copying FILES to a different disc.

I did also ask about disk sizes as dd cannot directly clone to a smaller disk. In the absence of any response to the contrary, I tried it anyway to see if this plugin gracefully deals with that, but after many hours I can confirm that no, this plugin does not overcome that limitation, provides no warning of this and simply produces an unusable disk.

No matter, I wanted to confirm either way and will now use a different method of copying the drive to another and this thread will hopefully prove useful to others attempting to fathom the operation of this plugin.

None of this means I don't appreciate the work put in to make OMV what it is. Sometimes though, digging out little nuggets of important information is more painful than it needs to be.

Thanks, yes understand that, but the intended destination had just been erased in preparation for this. However, I also created an XFS file system on it and that is what prevents the disk appearing in the destinations pop up. Wiping it again allowed it to appear and cloning now proceeds.

However, the entire process is not clear. I get the need for safeguards to prevent inadvertent loss of data and once one knows, it seems clear enough, but when first presented with a disk copying procedure that lists no possible Destination it is rather obscure and could so easily have been made more understandable with some basic explanation on screen.

Thanks anyway for prompting me to realise having a filesystem on the disc was the problem.

Jumping in to this as I want to clone a data disk to another disk. Both disks are correct and seen by OMV, the destination being completely empty. When I enter Service/Disk Clone, I can select the source drive, but when I click on destination, nothing happens. No popup from which to select the destination, even though it is all in red saying it is required.

So something is screwy. Is it possibly that it requires the destination to be exactly the same size as the source? In my case it is only half the size, but still 3 times larger than the data actually on the source.

I could manually set up rsync, but an easy to use OMV plugin seemed the obvious way to do it. Why is it failing so spectacularly in not allowing me to specify a destination?