Nobody interested in this issue? So sad...
I just noticed such a line exists within the output of dmesg of my Rpi3 running OMV 3.x:
systemd: Cannot add dependency job for unit openmediavault-udev-write-dev-rule-link-rules.service, ignoring: Unit openmediavault-udev-write-dev-rule-link-rules.service failed to load: No such file or directory.
I think the OMV running on my Rpi3 is behaving absolutely normal besides that single line.
So what is openmediavault-udev-write-dev-rule-link-rules.service? Is it possible to fix the missing service?
I believe there was power failure while updating to OMV 3.0.96 from 3.0.95 and I made apt re-install the openmediavalut package after that, could something went wrong there?
It hasn't been officially declared as stable but it is very stable for me and others. Depends on the plugins you use as well.
Is OMV 4.x in a "beta" state where features are frozen?
I always enjoyed new features/improvements from newer kernels and I would also want OMV 4.x on my J3455 board.
It seems that people are still having problems with the installation process of OMV 3.x (being really REALLY slow) on Intel Apollo Lake platforms. I figure I should write this down so people don’t have to get their hands dirty moving drives around/changing bios settings like crazy just to get through the installation.
I guesse the problems were caused by both the iGPU and the power management, so I tried to change some of the boot parameters of the installer, with a ASRock J3455-ITX board (nothing's attached to the board besides two memory sticks, a 64G SSD, a VGA monitor and a USB keyboard):
1. change "vga=xxx" to "vga=normal" followed by "fb=false"
2. add "acpi=off" after "fb=false"
Well you won't have a nicely-placed UI with "vga=normal" and "fb=false" but the UI will still be usable.
I only tested with all three modifications in place and they granted me a nice and easy installation but I'm thinking "acpi=off" along should do the trick... you are welcome to try it out.
The installer was trying to configure the NICs when I started writing this and by now the installation is done, so you have some idea about how smooth things can be.
Problems with Realtek drivers?
From my experience Realtek GBE controllers are likely to have problems with default/stock drivers on many Linux distros.
Well it's good OP got it straight.
Synology’s DSM (Synology’s custom-made OS, it’s awesome, most of the time), is actually a Linux kernel based OS. It lacks many packages that are considered as "standard default built-in packages" in common Linux distributions.
It also have many Synology-made packages (and custom-made drivers). There are articles out there telling people how to install the "missing packages" to DSM and I knew a few guys who successfully "enhanced" their DSM in that way.
But that's that, I would be surprised if OP actually manages to get a full set of Debian packages running on DSM.
Given that, without a fully functional Debian, there is no way to run OMV, I think OP you and your friend is done here.
If you want to build your own NAS and run OMV on it, you'd have to start from... picking up parts from computer DIY parts vendors.
There are words around that you can install basically any Linux distribution on a QNAP NAS, but that's still too troublesome for me so I didn't look into it.
I am testing, but it is strange.
If I do not connect the Odroid to the router there is no problem with the network, at the moment I reconnect the ODROID, in several minutes the network fall down.
Where should I look?
Maybe your OMV machine is generating too much network traffic and your router get overloaded?
3.0.68 changed from /media to /srv for data drive mount points. This broke the unionfilesystems plugin (mergerfs) and has been fixed. Try rebooting since this will rewrite your fstab and mount the drives in their original location.
I just updated to 3.0.68 but all my data drives are still mounted under /media. Is this expected behavior? Reboot has no effect on this.
"a user named 1001 in OMV with high level access" probably means there's a user whose name is longer than 8 characters and the user is assigned an id of 1001.
You can have look at /etc/passwd to figure out which user is that. A little google will give you much more than enough info about how to "read" /etc/passwd.
(Or something's very wrong and the mapping between user id 1001 and the username is lost, in that case I have no idea how to repair your OMV.)
It's very strange to see user id 1001 with high level access as 1001 is an id in non-privileged range.
I don't know how to find out what is causing folders to copy, but I do suggest you to reinstall ASAP.
Recently I began to receive emails about the following monit alert:Code
Mar 27 04:45:01 openmediavault rrdcached: Received FLUSHALL Mar 27 04:53:46 openmediavault monit: 'nginx' failed protocol test [HTTP] at INET[127.0.0.1:80] via TCP -- HTTP: Error receiving data -- Resource temporarily unavailable Mar 27 04:53:46 openmediavault monit: 'nginx' trying to restart Mar 27 04:53:46 openmediavault monit: 'nginx' stop: /bin/systemctl Mar 27 04:53:46 openmediavault systemd: Stopping A high performance web server and a reverse proxy server... Mar 27 04:53:46 openmediavault systemd: Stopped A high performance web server and a reverse proxy server. Mar 27 04:53:46 openmediavault monit: 'nginx' start: /bin/systemctl Mar 27 04:53:46 openmediavault systemd: Starting A high performance web server and a reverse proxy server... Mar 27 04:53:46 openmediavault systemd: Started A high performance web server and a reverse proxy server. Mar 27 04:54:17 openmediavault monit: 'nginx' connection succeeded to INET[127.0.0.1:80] via TCP Mar 27 05:00:01 openmediavault rrdcached: Received FLUSHALL
The system load is typically below 20% all day long. I don't think Transmission and a few scripts running wget/curl can overload a J3710 CPU + 8G Memory.
The alert messages were sent once a day, or somewhere close to that frequency. Everything's fine besides those alert messages.
What's going on there?
It looks like /dev/sdt is no longer working and you'll have to replace that drive before you can rebuild/recover your RAID.
Edit: at lease the OS thinks /dev/sdt is no longer working.
So you suggest I back up data I want, wipe storage drive, and do a clean install of OMV? Is there any easy way to delete folders besides SSH? Could I plug the storage drive into my windows PC to somehow manage the data? It's formatted xfs which windows doesn't recognize by default.
edit: If I want to back up to another drive, I'll probably need to go out and buy one. Transferring over my network is painfully slow.
You can also try ACL options from the OMV Web admin panel and then remove those folders through SMB, I think it should work.
One more step back, a USB-HDD enclosure + a Debian/Ubuntu VM should provide you with a GUI-based access to your data drive. You'll need to put the drive in that enclosure and connect it directly to the VM. But that seems to be too much trouble...first you'll have to get an 3.5IN enclosure and then setup a VM.
I don't trust those XFS drivers for windows (unless they came from M$), as a bug could (easily) permanently damage data on your drive.
Removing folders should be easy with SSH, but I figure it would be safer to copy the folders you want to another drive (maybe your PC if you have enough space) and just wipe the data drive.
Guess OP needs one of those commercial NAS systems with all the start up toutrials and customer support, not a free NAS OS
Same thing here.
Actually sourceforge did mess it up. Please refer to that previous post and smartmontools wiki site for more information.
A quick fix would be:
1. ssh into OMV3 as root
2. cd into "/usr/sbin/"
3. open "update-smart-drivedb" as a text file (vim, nano or whatever, your call).
4. locate that download URL "http://sourceforge.net/p/smartmontools/code/HEAD/tree/$location/smartmontools/drivedb.h?format=raw"
5. change "http" to "https", save & exit.
6. cd into "/etc/cron.weekly", manually run openmediavault-update-smart-drivedb ("./openmediavault-update-smart-drivedb")
7. you shouldn't see any error message.
The problem occurs because you are using the smartmontools from the Jessie backports. The official version supported by OMV3 is Debian Jessie 6.3+svn4002-2+b2. You have to find out yourself how to fix that issue. Please note, OMV does not use backports because of exactly this situation, different versions make always trouble, thus OMV only supports the stable version and no backports.
Thanks for the heads up. But I don't know if I'm reading this correctly, since what I got from
I'll take what you said as "I have no idea what's going on in your machine since you are using Jessie backports, which is not supported by OMV3. You are on your own now."
Actually the devs at smartmontools had figured out where the problem is. If you would like to pay a visit to their wiki site you'll find this:
Update the drive database
The drive database file drivedb.h can be updated separately with the following command:
This command uses curl, wget or lynx for download. A proxy server can be specified by the environment variable http_proxy (lower case only), see the man pages of the above commands.
The Windows package provides update-smart-drivedb.exe. It reads the proxy configuration from IE registry key.
The above update method does no longer work for smartmontools older than 6.5. The update-smart-drivedb tools from 5.40 to 6.1 use a download URL which is no longer valid since sourceforge platform upgrades. Releases 6.2 to 6.4 of the script use a HTTP URL which does no longer work since sourceforge site changed to HTTPS-only.
So I'm right about what happened: sourceforge messed it up.
I would be really happy if you can update OMV3 to use smartmontools 6.5. For now I already added that "s" to update-smart-drivedb so I'm not worried in any degree.
You have a nice day, votdev.
Basically the error message says:
/var/lib/smartmontools/drivedb/drivedb.h.error: rejected by /usr/sbin/smartctl, probably no longer compatible
I took a look at the rejected file, it contains a whole bunch of smart related info and nothing seems to be wrong.
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-4.9.0-0.bpo.1-amd64]
Is it just me or something's wrong on where the drivedb.h is hosted?
At Thu 09 Feb 2017 07:40:02 AM EST, OMV tried to update drivedb.h and it seems like the uodated drivedb.h was rejected by smartctl.
After that openmediavault-update-smart-drivedb fails everytime.
Probably not a problem on my side.
I found a file named drive.h.error under /var/lib/smartmontools/drivedb.HTML
<html> <head> <title>302 Found</title> </head> <body> <h1>302 Found</h1> The resource was found at <a href="https://sourceforge.net/p/smartmontools/code/HEAD/tree/branches/RELEASE_6_4_DRIVEDB/smartmontools/drivedb.h?format=raw">https://sourceforge.net/p/smartmontools/code/HEAD/tree/branches/RELEASE_6_4_DRIVEDB/smartmontools/drivedb.h?format=raw</a>; you should be redirected automatically. </body> </html>
The file is generated everytime openmediavault-update-smart-drivedb fails and the content is the same.
So sourceforge messed it up?
How can some random guy upload a php file to your Nginx server and have the server run it?
Don't you think your security is already trashed if someone managed to do that?
Could not replicate the issue. So I guess something's wrong on your side rather than on OMV's side.
ASM1061 is a pretty decent PCIE 2.0 to 2x SATA 6G/s bridge chip. In some builds I've seen this card bringing 2 HDDs to ~100MB/s.
A lot of motherboards came with an ASM1061 on board so I would say OP you should expect a lot more than 50MB/s.
You could have gotten a defective expansion card, I was told these cards were VERY poorly constructed. Also it could because there are problems with your device drivers.
If you can't get it working by all means, try a full PCIE expansion card, if your build allows.
Edit: A quick test of an ASM1061 built into one of my motherboards showed ~150MB/s write speed to a ST3000DM001 (dd/Ubuntu 16.04 LTS/Linux Kernel 4.4). So definitely you should expect higher speeds OP.