Posts by crashtest

I'm not sure what permissions route TD took in his video, however, I see that you have user1 with read/write to folder "Very" using an ACL. Why not go a different route and use standard permissions?

In OMV, under Access Rights Management, User; create a username + password that exactly matches the username + password that you use to log into your Windows or Mac client - the same client that you're using to open the share. Try it and tell us what happens.

**Edit: I see this was overtaken by events.**
All's well that ends well.

(Note that I don't have an answer for this...)

While I might not be looking at the screen captures correctly, it appears that 3 disks are disappearing. Are you using a USB enclosure?
I'm assuming that you have tried another USB port.

OK, let's see if I understand this:

If you share a local folder on OMV, it works and you can write to it.
If you share a local folder on the Synology box, it works and you can write to it.

Now you're attempting to remote mount a Synology network share, setting that up as an OMV local shared folder, then attempting to create a network share on OMV. Is that it?

If that's the case what I think you're running into is a permissions conflict. If you're accessing an OMV share, over the network, you're doing it by username + password from the client. That username+password is not likely to be the same username + password that remote mount is using to access the Synology share. I don't believe permissions can be "tunneled" like that. For something like that to work, it might be necessary to set "Other's" on both boxes to Read/Write and the SMB network shares to guests allowed.

This is not a good idea for a couple reasons:

1. This would create 2x the network traffic. If copying or streaming a file, it would have to pass over the network, from the Synology Box to OMV, then over the network again, to get to the client. (This "relay" may create issues in itself.)
2. To clear up potential permissions issues, to see if it would even work, it would probably be necessary to set permissions on both shares, on both boxes, to "Others" Read/Write. (Which is the equivalent of MS "Everyone" Read/Write.) With SMB set to "Guests Allowed" with write, anyone could write (or delete) from either server.

With the above noted, I don't know whether it would work or not. Testing would require a two machine setup. With that noted, I regularly replicate between two machines for full server backup and, in one instance, I'm using remote mount as the path between the two boxes. But the files and folderss themselves are local with the local OMV server handling permissions for network share access.
_____________________________________________

My advice would be to set up network shares on the server where the data exists. It's a lot less complicated and more secure.

Since you have the R-PI image downloaded, I'd reflash the card and start the script again. That's the clean way to do it.

You could go to the Raspbian forum and report the problem with the Russian mirror. You have the IP address and screen shot. But, by the time you do that, they'll probably be aware of it.

It's like a power outage. The hot second power goes out "someone" is calling it in. But when it's restored is another matter altogether.

I'd give it a day or two, or at least until the end of the next working day in your time zone. (Friday) That gives the admin's time to discover there's a problem with your mirror.

In consideration of the mirror issue,

Quote from lotusd

Any ideas?

try again, later.
__________________________________________

Where are you, geographically?

I ran through a build of the latest Raspbian image (May 27) with an R-PI4, and installed OMV. There were no issues.

There have been some problems with mirrors in the last few days. You might try a straight forward install one more time.

If that fails, sometimes using the net install version of Buster and installing by script may work. You can find a process for doing that -> here. You would be using the document titled Installing OMV5 on i386, 32-bit, platforms. The only difference would be, when you go to the Debian down load pages, get the 64 bit version of Debian Buster net install (versus the 32 bit version mentioned in the doc). Everything else is the same.

BTW: I have an older commercial server with Xeon 5000 series processors and it's working fine with OMV. It's an Intel server with intel nic's so, if your add-in Intel nic isn't cutting edge, it should be recognized.

With SALT being in control of OMV5, I have yet to learn how to manually edit OMV's config. (Regrets.)

So, I'll take it that when you're installing Debian and downloading additional packages, the install stops.

There seems to be a LOT of software / network downloading issues during the last few days. -> Thread . The first and easiest thing to do is wait a couple days.

Start with Storage, SMART, Devices tab and, assuming the drive is still there, click the drive and the EDIT button, etc. *You may have to delete Scheduled tests, if any, from the Scheduled Tests Tab first.*

There's also, System, Notification, the Notifications tab and the SMART check box, if stopping all SMART e-mails is desired.

Are you installing the 32 bit Debian Buster version, by script?

Quote from LarryTX

Doesn't seem to work. Just the same errors. Is there another script, perhaps with other repositories. /------/ No matter what this doesn't bode well for OMV.

There are other repositories but, when you attempt to access raspbian repositories (for example sjc02.svwh.net:80), a server name is supplied, that is tied to a mirror that is physically close to you in the network. (If you're in Miami, Florida, you most likely won't be pulling from a Canadian mirror.) This is why some users may have a problem with a build, where others do not. There's nothing that can be done about repository server or network issues, other than to wait one to a few days. (You could visit the Raspbian or Debian forums. Sometimes these issues are posted.)

Put this into perspective. Server admin's running these mirrors are often doing it part-time and/or for free. Moreover, this is open source software, that is set up for server operations without the gigantic CAL (per-Client Access License) price tag. With that in mind, just a bit of patience may be required.

Quote from tblazon

Do we have to start from scratch?

I would. A clean format, reflash the image and start from there. The preliminary stuff is just a matter of some minutes.

E: Failed to fetch http://mirror.sjc02.svwh.net/r…n/raspbian/pool/main/c/cu ps/libcups2_2.2.10-6+deb10u3_armhf.deb
Cannot initiate the connection to mirror .sjc02.svwh.net:80 (2606:c680:0:b:3830:34ff:fe66:6663). - connect (101: Network is unreachable)
Could not connect to mirror.sjc02.svwh.net:80 (72.5.72.15), connection timed out
_______________________________________________________________________________________________________

It appears that the R-PI mirror, in the region you're in, may not be working correctly. The mirror could be saturated with requests, or the network path to the server may be down, saturated or, otherwise, experiencing problems. It happens. During this last holiday weekend, at least one other user was affected in a similar manner.

While it may be a bit inconvenient, give it a day and try again tomorrow.

I can see it now,, wider spread use of ZFS with an R-PI4. There are ZFS zealots that have already done the same with the old, slower, and memory limited models of the R-PI. -> Blog

While it's certainly not the best solution, I think you could do it.

But, remember, your parity drives provides your ability to restore and, as others have already pointed out, USB is not known for solid reliability. In the scenario where you'd need to use USB connected parity disks to restore, the restoration of a 4TB drive would take a long time (a very long time over USB 2).
_______________________________________________________________________________

Some thoughts:
It seems you're outgrowing your storage.
The first possibility might be to start swapping in 8TB drives, in place of the 4TB drives.

If it was me, I'd start building a new server with much larger drives. As much as you have stored, if you're stretching the capacity of 4TB X 8 Drives, you need to be thinking about a backup server for some redundancy in any case. Cloud storage is useful for backing up important files but restoration of bulk data is not fast.

I don't know what the IP address is for your server (OMV) - but it appears that a client may be trying to use OMV as a NETBIOS "WIN'S server."

The first thing I'd want to know is which client is using the IP address 192.168.1.138. If you find it, turn it off, and clear OMV's syslog. Since you're getting requests every second, you should know quickly if this client is responsible.

On the server side, I don't know if this will help but:

Under Services, SMB/CIF, in the Settings tab, I have WINS support enabled and Local Master Browser disable.

Quote from encinoman

only Quiet boot but I gather that's something different.

RE your BIOS, you'd want to disable "Quiet". Then you might see the full BIOS boot sequence with messages and interrupt key sequences, to get into your card's setup.
____________________________________________________________________

Also, note what geaves said about the drive cage.

The following is offered as a cross check of your hardware setup:
Most drive cages require at least 1ea, 4 pin, molex connection to the PC's power supply. Some of them require two.
(Daisy chained molex connectors, as some power supplies are wired, are fine but in the case below, two connections are most likely required for all slots to work.)

Another thing to note:
Your first post says you have a "HBA" that you flashed to IT mode. To connect 4 drives with a cage like the above, you'd have to have 4 individual SATA connections. To make that work, you'll need a SAS/SATA breakout cable for your HBA similar to this. -> Cable

Have you given any thought to testing your hardware?

How about a fresh rebuild of OMV, or restoring OMV from backup?