Posts by dev_willis

    Always the suspect; seldom proved guilty.

    How did you erase, format, and mount the disk in OMV?

    OMV was not the suspect, initially. I assumed I had failed to account for something. I still wouldn't say that it's been proven to be OMV but given that I was able to successfully wipe, format and mount the drive in Ubuntu, DietPi and Windows, it's looking like it must be something to do with OMV since that's the only place it doesn't work. I'm sure it's a few different things coming together in some unanticipated way. Perhaps something about the combination of OMV, an RPi4, and the size of this drive. I'm just guessing tho.

    Below is an overview of what I tried. I had some extended discussion with crashtest about it in this thread as well. I didn't intend to highjack that thread but I couldn't get crashtest to come look at this one (I also had some trouble getting him to read and understand my posts and wound up repeating myself a lot. I assume he must be busy.)

    I tried to erase it with the "Wipe" button in OMV. When that didn't work, I tried it with the `wipefs --all --force` command but had the same problem. I tried it a second time as well per crashtest's advice but it didn't help.

    I tried to format it from within OMV and, when that didn't work, I tried it with `gparted` but that failed as well. It kept telling me the backup GPT headers were corrupt and that it was rebuilding the backup from the main headers but whatever it was doing didn't seem to stick because it rebuilt them a dozen times or so in total but still kept saying they were corrupt. I ran `gparted` on Ubuntu but it didn't find any problems with the headers so I'm not convinced they were actually corrupt.

    I was never able to get to the point of mounting the disk while working entirely in OMV because I was never able to create a file system with it. Since I had no trouble with the drive in Ubuntu, I created an EXT4 file system there and then tried mounting that in OMV but still had the same issue. I was beginning to think the problem might be with the RPi4, so, to test that, I removed OMV and installed DietPi. I had no issues at all wiping, formatting and mounting the drive on the RPi4 while running DietPi. So, I set up the Samba shares like I needed and have just been using DietPi ever since. OMV was overkill for me anyway.

    Just FYI, I was never able to resolve this. I have no trouble with this drive on Windows or Ubuntu desktops and it worked fine on the RPi4 after I removed OMV and installed DietPi instead so it seems like it must be some obscure bug in OMV.

    I checked but the only drive entry there was for the working drive.

    I was beginning to suspect that the Raspberry Pi itself was somehow causing the problem so I installed DietPi to see if the problem persisted. However, I had no trouble formatting and mounting the drive on the Raspberry Pi with DietPi and I have successfully created and tested Samba shares for both drives. So, it seems like it must be some kind of bug in OMV after all. It's beyond my ability to troubleshoot it any further though. I'm just going to run with DietPi since it's working fine. I can even run a lightweight Node.js server this way too, so that's nice.

    Thanks for your help.

    I hadn't thought about what would happen if the controller failed and I couldn't get another one. I've just assumed MediaSonic would take of it, one way or another (tho my backup strategy does account for such an eventuality). Still, that doesn't really speak to the question of reliability.

    I configured one of our desktops to dual-boot Ubuntu so I could test further. Using the "Disk" utility, I was able to create and mount an EXT4 partition without any errors. I unmounted it, plugged it back up to the RPi, and tried to mount it in OMV but got this error:

    These MediaSonic PRORAID enclosures are purpose-built for running RAID arrays. Serious question: what makes a software RAID built and maintained by a single guy in his spare time more trustworthy than a professionally-built hardware RAID? SnapRAID looks cool but it seems like a lot more trouble than simply using the box as-intended (assuming I can get it working as-intended), plus it puts extra load on the RPi.

    Please don't think I'm here to accuse OMV of being at fault for anything. My assumption has been that I have failed to properly account for something. I have two of these enclosures, a 4-bay and an 8-bay, and the smaller one I have already set up in an identical manner with no issues and am currently sharing it on our network as a file history target. Since one of these devices is working properly in OMV, I know that what I'm trying to do is possible. Since the one that isn't working in OMV works in Windows and there's no indication of a failure of any kind, I think it's unlikely the device or the drives are faulty.

    But there must be something different about the two. The working device is 2.73TB while the one I'm having trouble with is 27.3TB so it crossed my mind that the size of the volume could be the issue. XFS itself supports volumes much larger than this but I don't think that necessarily means the software or hardware does. Perhaps the RPi can't handle a volume this size? Another possibility is that there's some difference in the firmware between the two that Windows supports but OMV doesn't, although this doesn't seem likely. The error that I'm getting about the backup GPT headers being invalid and needing to be regenerated makes me think something from Windows is hanging around and getting in the way. I'm not sure why I can't just blow away all the headers and create new ones though.

    I'm confused. Are you trying to format a RAID5 array that has been created in an external housing, with XFS?

    Yes; exactly.

    As for the SMART stuff, I think the reconciliation of the two statements is that the status is unknown to OMV because it can't directly verify it but the device itself is saying that the drives are all passing. I don't know anything about the internal workings of the device but I would expect that it performs periodic SMART tests on its own, at least in short. Whatever it does, it has some mechanism for detecting when a drive fails and reporting that by changing the drive's status light from blue to red, which has not happened. I've read that this information can be verified with Hard Disk Sentinel but I haven't done that yet. I've never had any issues with this device and even now it still works normally in Windows so my feeling is that it's some kind of configuration or procedural issue.

    The SMART status is "unknown" in the GUI. In the extended information it says the result of the "overall-health self-assessment test" is "PASSED." This is a MediaSonic PRORAID enclosure with four drives in a RAID 5 array. The enclosure indicates all the drives are good and I've been using it in Windows for a couple years now without issue. I don't mind wiping the drive but isn't the "drive" really virtual? Meaning, rather than wiping it, can't something somewhere just be deleted and recreated?

    In my case, I'm not trying to take over any existing files (and the file system is exFAT, not NTFS, if that makes a difference--still a foreign file system but supposedly well-supported in linux through exfat-fuse). I used Windows to create and format the volume because I was unable to create an XFS volume from within OMV due to a mysterious error. I'd still prefer to do it that way if I could get it working.

    I'm having this problem too. I don't know what may have been discussed on Reddit or why OP has been told this is a bad idea but what's the actual problem here? It sounds like it can be fixed but no one has said how. The share is successfully created despite the error but the permissions must not be correct. It lets me copy or create one file and then after that I get an error about the request not being supported. No more files can be copied or created after that and the one file that I was able to copy or create can't be deleted. The drive was set up in Windows and is formatted exFAT as a work-around for another problem that I have an open question about here: Can't create file system: read error 27 - General - openmediavault

    Any advice? Thanks!

    I have a MediaSonic PRORAID enclosure (RAID 5, ~27.3TB) that I want to share on our network as a backup target but whenever I try to wipe this disk I get the following error:

    When I try to create a file system on it I get this error:

    Error #0:
    OMV\ExecException: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; partprobe '/dev/sdb' 2>&1' with exit code '1': Error: end of file while reading /dev/sdb in /usr/share/openmediavault/engined/rpc/
    Stack trace:
    #0 /usr/share/php/openmediavault/rpc/ Engined\Rpc\OMVRpcServiceFileSystemMgmt->Engined\Rpc\{closure}('/tmp/bgstatusNN...', '/tmp/bgoutput4u...')
    #1 /usr/share/openmediavault/engined/rpc/ OMV\Rpc\ServiceAbstract->execBgProc(Object(Closure), NULL, Object(Closure))
    #2 [internal function]: Engined\Rpc\OMVRpcServiceFileSystemMgmt->create(Array, Array)
    #3 /usr/share/php/openmediavault/rpc/ call_user_func_array(Array, Array)
    #4 /usr/share/php/openmediavault/rpc/ OMV\Rpc\ServiceAbstract->callMethod('create', Array, Array)
    #5 /usr/sbin/omv-engined(537): OMV\Rpc\Rpc::call('FileSystemMgmt', 'create', Array, Array, 1)
    #6 {main}

    I've poked around with gdisk and fdisk and cfdisk and tried different repair/rebuild/delete/create options but no matter what I still get this same error. I don't fully know what I'm doing tho so I may not have done the right thing or in the right way. However, I can plug it up to a Windows desktop and use Disk Management to delete the volume, create a new one, format it as exfat and then plug it up to OMV and it will mount and I can share it.

    What might be the problem here? How can I go about troubleshooting this? I have another, older, smaller, MediaSonic enclosure (RAID 5, ~2.73TB) that I'm already sharing the same way on this server and it's working fine.

    Thanks in advance!

    I'm trying out OMV for the first time on an RPi4 and have been very pleased with it. I'm sharing a couple USB drives on the network via SMB and it's working well for me. However, there are times when Windows is unable to find the server on the network and it will continue to be unable until I run the network troubleshooter. The troubleshooter finds no problems and allegedly takes no action but after running it I can then open up the computer on the network, see the shares, and use it normally. No amount of time or attempts prior to running the troubleshooter helps. It seems to happen after it's been inactive for a while, like something's gone to sleep. I assume running the network diagnostics must somehow wake whatever it is up. During this time I can log into the web interface and use it normally but doing so does not fix the problem. So maybe the problem is in the workstation?

    If anyone has any ideas they're willing to share about why this is or what might be done about it I'd be appreciative.

    The doc currently says that creating a new user is "for server admin purposes" but the user created in the example does not seem to have the necessary permissions to do any administrating. And if the "admin" user can't be removed anyway, why create a new user at all? Why not just change the password on the "admin" account?

    It just occurred to me that this probably means for Linux server admin purposes, not OMV server admin purposes. Right?

    Ah, I see. I thought I was creating the user that would access the web interface and the note was just about not trying to create an account with those names. I was able to log in using the default "admin" and "openmediavault" user/pass combo and access the full system again. There doesn't appear to be any way to change this default password from within web interface so I changed it from the CLI. Was that the right way to go about it?

    I'm not a sys admin, I just know enough to get around, so perhaps this is obvious for experienced users but I feel like it would be helpful to cover it in the getting started docs, at least for people like me. The doc currently says that creating a new user is "for server admin purposes" but the user created in the example does not seem to have the necessary permissions to do any administrating. And if the "admin" user can't be removed anyway, why create a new user at all? Why not just change the password on the "admin" account?

    I'm amazed how fast I got responses here. You guys are great. Thanks!


    I'm trying out OMV for the first time, on a RPi4, and following the instructions I found here:…ing_OMV5_on_an%20R-PI.pdf

    Starting on page 17, under the "Adding a new Administrative User with SSH access" section, the instructions say to add a new user and assign the groups adm, backup, sambashare, ssh, sudo, and users, which I did. I saved, verified that I could successfully ssh to the device, and then, per the instructions, deleted the "pi" user. Then I logged into the web interface with the admin account I had just created. It now appears that I don't have any ability to administer the system. The only thing I can access is the email address and password for this user. Nothing else is available. Not sure if I missed something or if these instructions are just bad.

    So, my question is, can I fix this from the CLI? Or do I have to blow it all away and start over?