Trying to add existing data drives to fresh install of OMV5 with Shared Folder path of "/", getting error

1. offizieller Beitrag

    Hello! My father has something like 12 external HDD's of Backup's that i convinced him to let me build a box around.

    I have some prior knowledge of OMV5 as i have set up a box at my office and its been chugging along for quite a bit now, but with the office install, i wiped the drives as they were new and created filesystems from there.

    He is a Mac user and the drives i am trying to share are hfs+ and exfat formats. I'm getting some issues adding the Shared Folders of the drives using "/" as the path when i create them. The drives are mounted and already have filesystems on them but i must suck at Googleing as i have not been able to share them without errors. I used TechnoDadLife's video to setup the system (which was a huge help!) and tried this link to add the Share to no avail.


    The error I get when i try to share the 6T drive with the path of "/" i get.....

    Failed to set file group to 'users' for '/srv/dev-disk-by-uuid-2f482f28-570c-3c88-a4f7-4f5b4a2f968f/':

    Error #0:

    OMV\Exception: Failed to set file group to 'users' for '/srv/dev-disk-by-uuid-2f482f28-570c-3c88-a4f7-4f5b4a2f968f/': in /usr/share/openmediavault/engined/rpc/sharemgmt.inc:344

    Stack trace:

    #0 [internal function]: Engined\Rpc\ShareMgmt->set(Array, Array)

    #1 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)

    #2 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('set', Array, Array)

    #3 /usr/sbin/omv-engined(537): OMV\Rpc\Rpc::call('ShareMgmt', 'set', Array, Array, 1)

    #4 {main}


    Any ideas on how to Share these drives in their entirety? Hopefully my lack of CLI isnt too heinous.

    Imgur album

  • KM0201

    Hat das Thema freigeschaltet.
    • Offizieller Beitrag

    As I told you on Reddit, you can do this, but I wouldn't (below is just one reason).


    Next cloud OMV5 RPI


    Create a folder, "6T" for example... and organize all your data that users will access (music, movies, documents, etc..) under that folder. Anything users don't need access to (Container folders, etc.).. put outside of the 6T folder.

    I did this with default permissions and it still errors out. https://imgur.com/gallery/7Y7sokL


    Edit - im unsure why Imgur deleted my post saying it was against tos. I got another drive working as i wiped it, made a new filesystem, and shared it with no issues.

    • Offizieller Beitrag

    You having a user doesn't change my opinion on doing this.


    To quote myself from reddit:


    I personally wouldn't do it, and I sure as hell wouldn't do it everyone read/write.


    Like I said.. can you? Yes. Should you? My personal opinion is no. Use the system the way it was designed.

    I agree it is more secure and will change the permissions once i can get the folder to even share. I have tried making a new folder to share on the drive and it "Failed to create the directory '/srv/dev-disk-by-uuid-2f482f28-570c-3c88-a4f7-4f5b4a2f968f/MasterFile/':" The only issue im having is getting any data on the drive to share via smb.

    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!

    omv 5.5.23-1 (usul) on RPi4 with Kernel 5.4.x

    Einmal editiert, zuletzt von dev_willis ()

    • Offizieller Beitrag
    Zitat von dev_willis

    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?

    Let's look at this from a few view points:

    1. If a disk is formatted on another machine, it is a "foreign" file system. When that disk is moved to a new machine; none of the accounts (with their security tokens) that created the filesystem, folders and files exist on the new machine. This alone can create issues.
    2. NTFS is NOT POSIX (Linux / Unix) compliant. Windows permissions work largely by ACL where Linux permissions work largely by Group. They do NOT map one to one. (There's a project to get NTFS into the Linux kernel but, for now, it's not there.)
    3. As an experiment, format a disk EXT4, populated it with some data that's accessible only root or by the group Users (set others = none), connect it to Windows and see what happens. Even with the EXT4 add-on for Windows, giving Windows the ability to read the filesystem, there will be permission issues. It simply won't be 100% "transparent".

    Rather than apply bandaids like "taking control" of files and folders with an administrator account, which permanently alters files and folders, it's simply easier to format a Linux disk EXT4 (or any of the other POSIX compliant native filesystems), and copy Windows files over the network into SMB (SAMBA) shares. Samba understands what Linux needs AND it can preserve Windows file attributes. This is far less complicated and it works very well.

    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.

    omv 5.5.23-1 (usul) on RPi4 with Kernel 5.4.x

    Einmal editiert, zuletzt von dev_willis ()

    • Offizieller Beitrag
    Zitat von dev_willis

    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)


    There's a difference between what is supported on the CLI (Kernel enabled) and what is available for configuration in a convenience GUI. If the file format is not available in the GUI, there's a very good chance it's a non-POSIX filesystem. Assuming that there won't be permissions issues with a non-POSIX filesystem, created by another operating system, is expecting a lot. If the file system is not available in the GUI, it makes sense that GUI permissions support may not be provided either. (OMV directly supports BTRFS, EXT3, EXT4,F2FS, XFS, JFS and, by plugin, ZFS. That's more filesystem support than most NAS releases.)

    Where exFAT is concerned, it seems that Win10 has problems with -> exFAT as well.

    Something to try:
    You could try connecting the exFAT drive to a Windows box, take ownership of the drive, then push everyone - full control at the root of the drive, recursively. (Still, that won't be as good as using a native file format for guaranteed support.)

    Zitat von dev_willis

    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 find this interesting. What error? When wiping a drive, if the error had something to do with GPT formatting, a second wipe attempt may be successful. (I know that's not intuitive, but it works)

    There's also wipefs on the CLI.

    The following "clears out" a drive's signatures, partitions, etc.
    Unmount the drive (if mounted) and run the following.

    wipefs --all --force /dev/sd?

    Where ? is the drive device path.

    While it's not really necessary, reboot.
    Wipe the drive in the GUI (so that the GUI knows it was done), then retry the XFS format.

    • Offizieller Beitrag

    Have you checked the SMART stat's for this drive, in the GUI?

    Counts in the following would not be a good indication:

    SMART 5 – Reallocated_Sector_Count.

    SMART 187 – Reported_Uncorrectable_Errors.

    SMART 188 – Command_Timeout.

    SMART 197 – Current_Pending_Sector_Count.

    SMART 198 – Offline_Uncorrectable.


    1 or 2 in the raw count would not be a crisis. 3 or more might be an queue to order a new drive.

    The follow is not serious but a bad cable or a loose connection can cause problems.
    SMART 199 - UltraDMA CRC errors

    (Usually hardware or cable related)


    ____________________________________________________________________

    The only thing I can think of, beyond the above, is overwriting the entire drive.
    After the wipefs command, the following will overwrite the entire drive with zero's. That will take awhile, depending on the size of the drive.

    dd if=/dev/zero of=/dev/sd? bs=1M

    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?

    omv 5.5.23-1 (usul) on RPi4 with Kernel 5.4.x

    • Offizieller Beitrag
    Zitat von dev_willis

    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."

    These two statements do not reconcile. That's the problem with some of these enclosures. Some of them filter (don't pass) SMART stat's to the host.


    Zitat von dev_willis

    The enclosure indicates all the drives are good

    If you can't see smart stat's this is an unverified assumption.

    Zitat von dev_willis

    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'm confused. Are you trying to format a RAID5 array that has been created in an external housing, with XFS?

    Zitat von crashtest

    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.

    omv 5.5.23-1 (usul) on RPi4 with Kernel 5.4.x

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden