Pinned New User Guide - Getting Started with Openmediavault

    • OMV 4.x
    • core
    • New User Guide - Getting Started with Openmediavault

      This guide is targeted toward new users with general knowledge of Windows and Mac PC's, and some understanding of their LAN.
      Intermediate users may find some topics useful, such as data and operating system backup concepts and techniques, and general navigation of OMV's GUI.

      This guide is a work in progress that is focused on the current version of OMV.

      Getting Started With Openmediavault

      Übersetzungen dieses PDFs können -> hier.
      Las traducciones de este PDF se pueden hacer -> aquí.
      Des traductions de ce PDF peuvent être faites -> ici.
      このPDFの翻訳はできます - >ここ
      ______________________________________________________________________________________


      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide
      Guide

      The post was edited 4 times, last by crashtest: edits ().

    • New

      Some quick remarks:

      • page 9: ARM-HF/ARM64 as hardware platforms don't exist, 'ARM' would be a better replacement in your whole document. There exist various Debian architectures though, those OMV supports for the ARM boards are called armhf and arm64. In the context of this guide the differentiation doesn't matter
      • page 9: OMV runs flawlessly with 512MB or even just 256MB and there is no relationship to performance other than in situations with storage being much slower than network throughput or swapping happening (and then it's almost all of the time a misunderstanding). Only if storage is way slower than network the more RAM the faster writes get until filesystem buffers are flushed to disk. Pointless.
      • page 10: the problem of the RPi or other ARM SBC appearing to 'hang' is mostly related to being stuck in I/O due to the OS running from average SD cards. Those show horribly low random I/O performance and as such everything slows down. Easy to check for by checking iostat 10 output and watching %iowait percentage. On those SBC that appear to hang this value will be high. Simple fix: grab an A1 rated SD card and the problems are gone.
      • page 11: transcoding when done the smart way doesn't require much CPU horsepower but VPU HW acceleration instead (Intel QuickSync or with some selected ARM boards like ODROID HC1/HC2 a special Emby version)
      • page 13: Good OMV boards like ODROID HC1/HC2 or the various RK3399 boards perform faster than 99% of x86 installations
      • page 28: It would be great to run SD Formatter again doing a 'Quick Format' not for putting a filesystem on the card again but since this will effectively do a TRIM operation on the whole SD card which will positively affect both SD card performance with old/cheap cards and life expectancy
      • page 28: 'Attach a monitor, keyboard and mouse.' -- nothing I would recommend since on some boards there will be no display output anyway and on boards prone to underpowering (RPi and every other thingy with Micro USB) the additional load due to USB consumers might increase undervoltage effects (and if voltage drops below 4.75V most probably HDMI displays won't work any more)
      • page 28: 'then verify it in one operation.' If verify fails then this is a sign of a bad SD card or write attempt (using USB2 ports or USB3 front ports on PCs highly recommended)
      • page 29: What about mentioning angryip.org and educating users that if they use their router's DHCP table it would be a great idea to simply assign a static DHCP lease there to skip all the 'configure static IP address' hassles?
      • page 34: 'A static address for the OMV server and setting the address of a public DNS server is highly recommended.' -- nope, that's just your opinion. Accessing devices by name works since decades and also in local networks
      • page 36: WRONG the 'Domain name' entered here is totally unrelated to Windows concepts (no AD domain), it's simply the local host's domain that will be assigned then. If you use OMV-RPi2 as Hostname and workgroup as 'Domain name' then you'll find a new entry 127.0.1.1 OMV-RPi2.workgroup OMV-RPi2 in the server's host file and now the server can resolve omv-rpi2.workgroup to its own loopback address (pointless). This is not related to any Windows browsing mechanism whatsoever and should remain the default (empty)
      • page 37: 'It is recommended that users assign a static IP address to the new OMV server that is outside the range of their network's DHCP server' -- nope, just your opinion. Assigning a static lease at the DHCP server is a smarter approach and becoming familiar with the idea that DNS also works in local networks as it works on the Internet for 3-4 decades is the way to go
      • page 37: 'It is also highly recommended that users set a public DNS address' -- nope, just your opinion. Also this will prevent local name resolution and as such introduce problems for no reason
      • page 38: Scheduled SMART tests mess up with drive spindown behavior with many if not most USB disks
      • page 38: Enabling monitoring will result in flash boot media like SD cards or USB pendrives wearing out faster even with flashmemory plugin enabled due to the RRD (round robin databases for the performance data) being flushed to 'disk' from time to time. Therefore it's disabled by intention on the ARM images
      • page 40: 'Users should update basic packages, selecting a group of 4 to 6 entries with check marks' -- why that? Users should update all packages in a batch regularly and especially prior to reporting any problems on the forum since often problems that are reported there have long been fixed in OMV or other parts of the Debian system.
      • page 47: 'Toggle the Local Master Browser to ON' -- this only adjusts Samba's OS level and makes Samba trying to win master browser elections as already explained (to no avail though). It does change nothing at all whether there's a local master browser (there is always one) or whether the OMV server is browsable or not. All this LMB stuff is from last Century anyway and doesn't matter for Windows users acting responsibly (using Win10 these days)
      • page 48: 'Public: Click on the drop down and select the Guests Allowed' -- nope, why? There exists neither a reason nor an excuse to use guest logons in 2019.
      • page 52: What's the reason to recommend fiddling around with /etc/fstab? Debian default is relatime so care to elaborate what benefits noatime should have on an OS drive? Same with disabling a swap partition. On the ARM installs there is zram instead of 'swap on disk' but what should be the benefit of disabling swap on systems that do not use zram already?


      MISSING: the whole guide lacks:
      • User management (setting up OMV users, explaining the defaults and why keeping defaults is a great idea, adding them to reasonable groups and how this relates to share settings) and
      • Authentication basics. With its focus on 'there is only Windows in this world' especially missing an explanation how Windows unlike every other OS tries to authenticate against SMB servers and how to resolve those basic authentication issues partially caused by guides recommending to use no authentication at all. They keyword is 'Credential Manager'

      The post was edited 2 times, last by tkaiser ().