Posts by klunkerbus

    I don't recall the error messages, but I also found getting notifications working (for the first time I'd done this) frustrating. I also ended up using STARTTLS, which as I understand it just adds a negotiation phase before transitioning to SSL/TLS. In my case I wanted emails going to a yahoo account, so I assumed that was a factor in SSL/TLS not working.


    I found all the instructions and videos out there on setting up notifications lacking on important details.

    So under file systems, you don't see your prior RAID listed? I did end up rebuilding my OMV boot disk from scratch, and when I connected up the data drives after the OMV install, the RAID5 array did appear under file systems. I just had to mount it and then go back and set up all the shares and permissions, but I it looks like I won't lose any of the data in the array.


    FWIW, I'm not using docker. My problem that drove me to reinstall was all of a sudden I couldn't boot from my SSD. I futzed with trying to fix grub or whatever could be causing that, but got to the point where I didn't know enough about what I was doing. I also opted to swap out the SSD for a HDD to rule out the SSD was bad/failing.

    systemctl enable fstrim.timer should enable the start at reboot

    Doh! I had even written using enable (not start) in my config logbook. I must have captured the wrong text when I copied it into the command window. Thanks for setting me straight. I now correctly show the fstrim.timer status as active(waiting) after a reboot.

    Just here to add that I also found both status queries to return "inactive (dead)".


    My OMV was also a recent fresh build, first to v5.3.4-1 and subsequently updated to v5.3.8-1. In my case the SSD is a SATA type connected to a port on the motherboard.


    EDIT: Running systemctl start fstrim.timer changes the timer status to active (waiting), but only until I do a reboot. Then it's back to reporting disabled (dead).

    I just did one approach with our new Windows 10 PCs at home using the File History scheme built into Windows 10. I have both of our machines pointing the storage area for file history to our RAID5 OMV server, and both are set up to archive any updated files every 30 minutes. What I like about it is by simply right-mousing on any filename in file explorer allows us to bring up a list of all the file versions stored on the server, and restore from any of them. Lost or deleted files are recoverable as well, but through a different process. You can pick and choose which folders are included.


    I still may implement say a weekly bulk backup using something else, but I started with this since it didn't require any additional tools or expertise to set up.


    EDIT: Windows 10 also still has the Win 7 Backup/Restore feature available where something like a weekly backup can be scheduled. Here again, the backup location can simply be pointed to the pi. Either of these would at least give you an easy path to implement something simple while you continue to look into what you think is the best approach for you to use.

    Helpful thread. Set up OMV with a plex docker on the same hardware a couple of times and everything worked fine. Transcode wouldn't work for some reason on a subsequent pass at reinstalling OMV again on that same hardware, and ended up here after ruling out every little nit thing I did different on this install round...


    EDIT: adding a follow-up comment that what I did different for this install was move the plex database to the harddrive instead of the SD card where the OS is for my Odroid HC2 board. THAT'S why I ran into the noexec problem on this latest install.

    ... I certainly will not touch the "physical disk properties". It seems that @Sylvania and @Adoby had a point there.

    Just adding my name to the list. On my HC2 running OMV 4.1.2 and kernel Linux 4.14.69-odroidxu4 with a WD 4TB drive, I painfully learned that trying to change the physical disk properties apparently leads to the by-label symbolic link being removed from /dev/disk/.

    FWIW -


    My setup: Odroid HC2 with WD 4TB red plugged right into the HC2. Running OMV 4.1.12 with kernel Linux 4.4.69-odroidxu4. This single-drive HC2 is used as a basic plex server, using the isioarmhf/plex docker.


    I can confirm that in both of my instances, I had attempted changing the physical disk properties in an attempt to stop the disk from spinning down after what seems like just a couple of minutes of no activity. How would a typical user know to not do this? The second time, however, my HC2 ran fine for about a week after I had made those changes, but the problem may not have revealed itself until I rebooted it at that time as a preventive measure.


    I know little about OMV internals and Linux in general. But at least part of what is happening is the "by-label" symbolic link to the named drive is removed from the system when this problem occurs. The /dev/disk/by-label directory where that link would be is even removed from the file system. Unfortunately, I didn't think to see if the references to the disk remain in by-id, by-partuuid, by-path, and by-uuid before I rebuilt the SD card.


    Again, I'm not a Linux guy and I don't know if removal of the by-label directory is *the* problem or just a symptom of a larger issue. I opted not to try manually recreating the directory and link, but that might be something someone could try as a recovery attempt.


    I didn't lose any of the hard disk data in either instance. All I had to do is rebuild the OMV SD card and set up shared folders and SMB shares just as they were before. I did lose plex configuration data that was on the SD card, but my latest rebuild has /config for the plex docker set to space on the hard drive where it probably should have been in the first place . Just a minor detail that none of the plex docker tutorials happen to mention for those running off an SD card...

    @Sylvania - how did this pan out for you?


    I've ran into the missing disk and unmounted disk twice now on my HC2 with a WD 4TB drive.


    Were you able to somewhat prove that messing with the disk properties was causing the problem?

    @ryecoaaron last three images to upload:

    That's now all the GbE enabled boards Armbian currently supports in a stable branch...

    Browsing through the forum, I haven't found an explanation on why 3_0_91 isn't available for the Odroid line. Any plans for that or a link to a thread that explains what the issue might be?


    Thanks in advance.