Maybe
your problem2 makes no sense, /---/
Thanks for responding to this. I was about to, and actually in the process, but it wouldn't have been helpful.
I'm continually amazed by questions, from impatient users, that require remote mind reading skills. (Hence, my signature.) -> Asking Questions.
I know that you have solved this, but by the way, if you are using the rsync server with rsync users, it does not use ssh.
You can use rsync over ssh but then it does not use a remote rsync server. But you get ssh encryption, which you don’t get with the rsync server method.
When following the -> tutorial using Remote Mount, an rsync server, SSH, rsync users, etc., are not required. All rsync jobs are "local".
Thank you for pointing to it. We will retry the doc, but our issue is that we fail already on Explore the New Network Share
Firewalls can be a problem if they're set to "high security" on the local LAN. That's a common mistake. High security can, effectively, isolate a Windows box allowing little more than HTTP connections to servers. You might try disabling the client firewall, just for a test.
________________________________________
Again, as noted in the User Guide, to start, the Shared Folder permission is Everyone Read/Write and the SMB share should be Guests Allowed.
(This is to get started. It can be tightened up later.)
In your SMB shares, in Extra Options, you could try:
client max protocol = SMB3
I noticed, in your first post that you changed the windows registry to SMB2 so you might try:
client max protocol = SMB2
Finally, from the client, you might try accessing the server share by IP address instead of by name.
\\IP-address\music
Adding to what gderf said:
Some browsers have an "incognito" or "private window" mode. These modes do not save cookies from use to use.
It is needed for the directory picker uses to show directories. I missed adding it as a dependency for the snapraid plugin.
Is the sharerootfs plugin needed for any of the other plugins (other than snapraid)?
Using ZFS:
I've rolled back data disk filesystems or individual folders or files, using snapshots generated by -> zfs-auto-snapshot. Recovery is easy once the .zfs directory (hidden snapshots) is made visible. Small restores, like files or folders, can be restored by a network client accessing a network share. It's pretty easy and straight forward.
Since an OMV boot drive is small; I back them up by using USB drives as boot drives and cloning them. I was giving some thought to setting up Timeshift for boot drives, but the thumb-drive cloning method works well enough.
- First, the disks you have listed under Storage, RAID Management are the disks in the array. Any other disks that are NOT listed under Storage, RAID Management are not in the array. The disks in your array appear to be:
/dev/sdd 931GB
/dev/sdg 931GB
/dev/sdh 465GB??
/dev/sdi 931GB
/dev/sdj 931GB
Under Storage, Management, using the Details button, you might consider reviewing the array's information. The information found there will reveal which disk is faulted or failing. Note that disk /dev/sdh is smaller than the remaining members of the array which, while it will work, is a RAID No, No. From appearances, /dev/sdh has limited the available space in the array. You would have more storage space (roughly +2.7TB versus the +2.2TB you have now) if you would have left /dev/sdh out of the array when you created it.
- Second. You can't add disks to an array (using the grow button) or recover the array (using the recover button) using a disk that has a file system on it. A disk, going into an array, must be "wiped" and clean before it can be used in a RAID array.
- Third. The disk that's formatted NTFS (dev/sda2 with 1.8TB) was not formatted to NTFS using the OMV GUI. This disk was likely formatted by Windows. In any case, it's not relevant to the questions below.
/dev/sde 3.64TB, a WD Elements drive formatted to EXT4, appears to be the external drive you're trying to use for backing up the array. It's large enough for the task.
____________________________________________________________
Here's what I consider to be the questions you must answer:
- Do you want to try to recover the array? If you attempt this and it goes wrong, that's it. There won't be anything nothing left to recover.
(OR)
- Do you want to backup the data that remains in the RAID array?
The answer to the above is your call.
_____________________________________________________________
If it was me, I'd backup the failing array to /dev/sde as soon as possible. If you go that route, depending on the version of OMV5 that you're using, the Rsync command line might be l-o-n-g. I checked, using a VM, and successfully backed up a RAID5 array to a single disk, using the "mount point" as it's displayed in File Systems. You'll have to add the mount point column as shown in the -> document I linked to before.
In my VM example, using OMV 5.6.24-1, the command line was as follows:
rsync -av /srv/dev-disk-by-uuid-ffbc3d2b-450b-4a4f-8bdb-96e18a641cee/ /srv/dev-disk-by-uuid-ad63a908-dcc3-46fb-8e38-dd3b01f3cfee/
(The above UUID's will not work for you.)
Hopefully your version of OMV is earlier than 5.5.20 so your disk mount points will be "by label". They're much easier to read and copy. If you have OMV 5.5.20 or later, with disks added after upgrading to 5.5.20, you may have to copy much longer Unique Identifiers into the Rsync command line. In either case, I'd recommend using Notepad so you can carefully copy and paste your mount points into a scheduled task command line.)
If you've reformatted it to EXT4, whatever was in NTFS format before is no longer there.
If you didn't add the external drive to the RAID array, it will be outside. Mount it and look at the Rsync section of the doc-link.
You could try connecting the "NTFS" formatted external drive to windows. If windows can't see the data....
Does Rsync also replicate data that I no longer see in theRaid?
Rsync can't "replicate" what is no longer there.
But if you can actually lose data or get damaged, it would be better to start from the beginning.
I understand you're in a bad situation but it seems that you can't access the data on the External drive and that assumes that the data is even there. On the other side of the coin, your failing array is not getting any younger or healthier. Where to go from here is your call but resurrecting the backup (NTFS formatted drive) doesn't seem to be going anywhere, you've had help from some of the forum's experts, and time is ticking by.
_____________________________________________________________________________
If you decide to use EXT4 on the external drive, formatted and mounted by OMV:
Take a look at this -> process. (Read through it first.)
You can use Rsync to backup and, later, to restore your data to a new RAID array. To set up the command line, your source drive will be the RAID array mount point or the device name. (From your screen captures, your RAID device name appears to be /dev/md127
After the backup, if you redirect shares to the backup external drive, you can get access to your data while working on getting your RAID array healthy again.
_______________________________________________________________________________
The second time around, you might consider ZFS or something else that runs a "scrub" on the array.) You also might consider turning on file system notifications and SMART testing. Both will give some advanced warnings of drive issues.
Worst case scenario, I will start the backup from the beginning again...3 more months of waiting!
Even if you managed a recovery, could you "trust" the result? I'd start over and this time I'd use EXT4 on the external disk.
(BTW: EXT4 drives can "read" by Windows with a driver or a utility. There are plenty of tutorials on how to do it. Here's -> one. Google Windows and EXT4)
If you're trying to backup a RAID array to a single external disk, consider using Rsync with EXT4 on the external disk. After the array is mirrored to the external drive, only changes are replicated. Rsync is fast.
???NTFS??? Why GOD?
In following this thread, I was wondering about the possibility of NTFS on the external drive.
So it's a hardware problem then
Well it is now!
But no, it’s not.
Still,,, 
!!!
The power supply on my main server went belly up,
If I had that, wall mounting would make sense. But, I'd consider leaving the top off (if it didn't affect air flow) just to look at the drives.
My only regret is not buying another one of these immediately to have as a spare. So far, not a single one of the more than one thousand previously sold on ebay by the original vendor has shown up there for resale into the third hand marketplace.
My only regret is missing out on buying one. Buy the time I read this thread, after you posted it, they were all gone.
it's testing, but as i know zfs pool can contain disk, partitions and files.
zpool and zfs woking fine with files,
OMV's GUI and the ZFS plugin, are about convenience. The plugin does not (arguably should not) provide ALL ZFS functionality that is available on the command line.
If you want to set up a pool using a mixture of disks, partitions and / or files, the command line is an option.
This might be helpful in securing shares. -> Permissions.
