This is awesome!
I honestly really like the default wallpapers since it gives a very distinct feel and style to the system. My issue was only that I have multiple hosts and it's nice to be able to tell them apart at a glance. Really more of a skill issue since two of their IP address are very similar. Really cool.
I have a Raspberry Pi 4 running OMV 7 smoothly and perfectly. Should I upgrade to version 8 now, or wait until the initial bugs are resolved? I’ve seen many people reporting issues after the upgrade. In my case, I have critical services running on Portainer and data on my hard drives that we use constantly, so I can't afford hours of downtime if the upgrade fails. Any thoughts?
Clone, test, upgrade. You’ll be in great shape. The only thing to keep in mind beyond this that I’ve experienced in the past when upgrading is that once an SD card itself failed when upgrading. I did have a a working clone, but initially it wasn’t clear what had gone wrong. Depending how long this has been running, now might be a good opportunity to migrate the OS to a new card.
An interesting application. My curiosity wants you to try it because I’d like to see if it works. If the data is critical in any way I wouldn’t try this, however. Generally speaking, I think using a separate disk is the wiser approach.
That’s a very good point about the permissions; I hadn’t even considered it.
You might still be able to glean some useful information from your backups such as config files etc.
Altering the behavior of OMV by dropping into CLI and making changes is something I wish to avoid!
If you want to follow the principle of least privilege to the degree of what you’re describing, I think you’ll want to become very comfortable with the CLI.
Perhaps you could post some examples of your files? Here’s a snippet of one of my compose files that shows the volumes section.
volumes:
- ${PATH_TO_APPDATA}/navidrome/data:/data
- ${PATH_TO_MUSIC}/music:/music:roFor my situation, I have a global environment file that binds appdata and music to two different drives on the host.
PATH_TO_APPDATA=/srv/dev-disk-by-some-id/appdata_share
PATH_TO_MUSIC=/srv/dev-disk-by-some-other-id/music_shareIf I were to replace one or both of those drives, I would change this path in that file. You could also hardcode the path to each volume, though not as easy to maintain. An example of this could look like:
volumes:
- /srv/dev-disk-by-some-id-number/shared_folder:/music:roIf your files look like this, you’ll need to replace “/srv/dev-disk-by-some-id-number/shared_folder” with a path to the new drive. A mapping should exist somewhere if the appdata lives on a separate disk.
One option:
Initialize the new app data drive and make sure the docker compose files all point to the new drive. It would be useful to know how you went about mapping this, ie in the env file, or differently for each docker compose files. Ideally it would be just updating a single line. This is where I would personally start before doing anything else, identify the mechanism in place that links the containers to the data.
From there, you’ll want to gain access to the backup data. The usb drive is connected but you can’t see it via GUI? Are you able to see it via ssh? If so, the cp command can copy the backup directory fairly easily.
If you have another machine capable of mounting the backup drive, you could use it to copy the backup files to the newly initialized app data disk. it could be a simple drag and drop if the new drive is reachable via network share. You could even set this network share up just for a temporary use.
Once your backups are copied and the docker compose files are correctly pointing to the data, bringing the containers online should restore their configurations to whatever point they were backed up.
Let’s start with the first step, how do your compose files map to the app data?
I highly recommend Timeshift if you’re interested in reverting to a previous point in time. It’s saved my bacon on numerous occasions when I screwed up and I just reverted to the previous day. Fortunately in your case, a new install isn’t that time consuming since you just want to start over.
In addition to Timeshift, I recommend you also implement proper backup solutions like clonezilla images or learn how to use the backup plugin.
bonjour'
la version de omv 8.04 est sortie mais pourquoi ne pas avoir fait en sorte de resoudre le soucis qui arrive quand on ajoute un utilisateur ?
Personnellement, je comprend pas .
De mon coté, j'avais essayé divers chose pour " corriger " mais cela n'avait pas fonctionné
I can’t speak for maintainers and moderators, but as a human being, I don’t think phrasing things in this manner is productive. Granted, I understand translation can alter the meaning in some context.
We’re incredibly fortunate to have access to this project free of charge. In addition to the software, there is a very active group of people on the forums that answer questions and provide the best support that they can. We’re better off collectively to stay focused on addressing the issues and maintain a courteous tone.
It sounds like keeping OMV 7 is the right choice for you in the interim.
New install 100%. I haven’t tried an outdated upgrade in a long time, but it was frustrating.
The first thing I would like to be able to achieve is getting both the SSD data partition and the mirror data HDD drive, visible as network locations on Thunar on devices elsewhere on the network, to enable me to read and write to those disks/folders from the rest of the home network. I haven't a clue how to do that.
I concur that re-reading the user guide will likely yield the best results.
I'm not familiar with Thunar, so I'll speak more generally.
Before I create any folders, I define my users in advance. This helps me to plan what folders I'll need.
When I'm setting up an OMV shares, I prefer this workflow: format/mount filesystem (sounds like you've done this already)-> then create a shared folder (perhaps done this too) -> then create an entry for that folders under whatever sharing services are desired (you might be missing this step). I do them one at a time because that's how my brain is wired.
Be mindful of permissions when creating the shares (ie everyone can read/write?). I find that writing it all down first can help if I have a lot of users.
I JUST setup an RPi 4 (4GB variant) with OMV 7 a couple of days ago and it seemed like the perfect candidate to upgrade to 8 since my other hosts are more mission critical. The RPi 4 is using the Wireguard, NUT, and Timeshift plugins along with the phased out FlashMemory.
Zero issues with the upgrade, took about 10 minutes. Very stable, as advertised. I would highly encourage anyone with RPi 4 to backup their system and proceed with the upgrade if their installation is fairly typical. In my case, I had made a few small changes in Linux but none of them created any problems.
I'll be upgrading the remaining hosts once I do a few backups. Remarkable turnaround given how recently Debian 13 came out.
EDIT: I upgraded the other two hosts with zero issues as well. Both are running OMV bare metal on AMD64. One of them has a lot of customization in Linux as well as a number of wacky Docker configurations and I was curious what might happen. But overall a pleasant and uneventful experience.
The above instructions are spot on. The process can be a bit overwhelming at first, but a little bit of research will get you where you need with regard to creating your own local database entry.
For my use case, I created a local file /etc/smart_drivedb.h. Within that file I inserted the specifics to my hardware which was an external usb device.
This format worked for me, though yours could be different:
{ "USB: ; JMicron SY-ENC50104",
"0x152d:0xa576",
"",
"",
"-d sat"},It might take you a few iterations to get it ironed out. I was scratching my head for a while until it finally worked. For the record, ChatGPT was zero help on this one, though you are more than welcome to try.
In a few hours I will probably be fully versed in how the system works but for an absolute newcomer this system could hugely benefit from a 'welcome' page with some 'first steps', 'concepts', and ideally some features to built-in wizards on how to do the most basic tasks.
Some of the points listed are a matter of taste which will ultimately appeal to some and not others.
Perhaps once you are more comfortable with the system you could contribute to the documentation? It could be beneficial for both yourself as you’d learn more about it, and it would be beneficial for newcomers in the future.
Sorry to bump an old thread, but I ran into a snag today due my own mistake. I'm using a secondary conf file to allow for reception of logs from other hosts per the discussion a little earlier in the thread. Everything was working fine until I did a recent update. I couldn't apply the changes and the error message detailed the rsyslog conf errors, most notably:
rsyslogd: module 'imuxsock' already in this config, cannot be added [v8.2302.0 try https://www.rsyslog.com/e/2221 ]
rsyslogd: module 'imklog' already in this config, cannot be added [v8.2302.0 try https://www.rsyslog.com/e/2221 ]I had unwittingly added duplicate imports for these modules in my secondary conf file, though it was not preventing normal operation. The history showed this had been the case for a while but I hadn't noticed it until the updates changes failed to apply. It was easy to fix once I had realized my stupidity, though I'm not sure why this inhibited the updates. Just a note for anyone playing around with rsyslog on omv lest they add duplicate entries like I did.
This is a difficult question to answer because philosophy will vary from person to person. I prefer more than one disk for redundancy, call me paranoid. Depending on how much data I can afford to lose, I have a the first backup that syncs every 12 hours or so, then a second backup that syncs once a week. If something gets sideways I can go back in time a bit before the data got changed. Sometimes there are more backups on other machines or remote sites depending on the configuration and the need.
With regard to the original post, I would recommend at least a 4th disk. Run an rsync task for critical folders on the RAID1 just to reduce the chance of data loss. I’ve lost two disks simultaneously before, and I vowed to wise up after that. Your machine can house 8 and disks just aren’t that expensive anymore.
I might be misunderstanding, but your current OS drive is still online? I understand a full disk clone is likely to fail. But one option might be the OMV-regen tool. I’ve used it before when switching to a new OS drive and it worked like a charm.
Just wanted to add something else I discovered. The SMART polling interval was set to 3600. I’m not sure why I did this in the first place, but I set it to something more frequent since it makes sense to do so. I haven’t seen a bad sector warning yet, though the change has only been in effect for a couple of days.
Display MoreThose are both good.
Strangely, your parameter 183 is different than my SSDs (samsung)
183 Runtime_Bad_Block PO--C- 099 099 010 - 20
I have an SSD with bad blocks that I don't care if it fails since there is nothing important on it. It has been like this for a few years. So, I guess it just depends on how well you can handle an OS failure on this system. I would not trust a full disk image of it. I would only back it up with something like omv-regen.
The 17% means you have 17% life used. It should have a lot of life left if it doesn't truly have bad blocks. If it were my drive, I would wipe it with zeros once or twice and then reinstall OMV on it.
I appreciate the advice. There’s another interesting wrinkle to this. Potentially this unit with certain firmware version can cause some fields to flip from 0 to 1 and back. Though the thread I saw was from 2019, so this evidence might be more anecdotal. Theoretically a firmware update could fix this, and possibly destroy all my data in the process.
If the OS failed, I’d be moderately inconvenienced. I’m leaning towards drive replacement, but my curiosity has prevented me from doing it already.
Good to know, regarding the flash plugin. I'll look to utilize it more often.
Regarding the long SMART test, yes I did run it. The print out contains a few of the fields from that long test. Is there a particular field I should be focusing on? If smartmontools is detecting bad sectors, I thought that perhaps (5 Reallocate_NAND_Blk_Cnt -O--CK 100 100 010 - 0), or (180 Unused_Reserve_NAND_Blk PO--CK 000 000 000 - 26) might give me some indication.
I copied the smart info from about a week ago to see if I can spot any key changes, but so far have not found any.
