Beiträge von crashtest

    I guess the cable has worn off? I'll further test it separately.

    Ethernet cables can be an "iffy" proposition. The pin/lands of the connectors are supposed to be gold plated but the plating is so thin that the force required to set the pins can remove the "molecules thick" gold plating. The wires of the sockets as spindly as well. (Sometimes, reseating or just giggling a cable end will do the trick.)

    Generally, a good quality factory made cable will be OK. Personally, I prefer making my own with good quality connectors and decent cable.

    This is speculation but this issue appears to be hardware related.

    When booted up I no longer have a local ip address starting with 192.168... Now starts with 172...

    This could mean that the port can't establish a "hand shake". The green light means the port is receiving but that says nothing about sending. You'd need to observe the port light at the interface, on the other end of the cable. (But, in both cases, the lights do not definitively declare that Ethernet is OK. It's just a first glance indicator.)

    Things to try:

    1. Reseating the Ethernet cable - both ends.
    2. Try another Ethernet cable.

    3. Try another port on the mobo. (If I have it right, this model appears to have 4 ports.)
    4. Try another port on the switch or router.

    If / when switching to another mobo port, run omv-firstaid on the CLI to configure the port.
    ___________________________________________________________________________________________


    Will I be able to resume using my RAID-5 with the content that has already being stored on it?

    Typically (as in 90% of the time), yes.
    I have to throw that caveat in there because there's no knowing what is actually wrong.

    I have a 5 HDD storage bay of 12 Terabytes in Raid 5.

    What is "a storage bay"? Are your drives connected to the mobo's SATA ports or are we talking about a USB RAID box?

    OMV is installed in my M.2 drive

    If you decide to rebuild, you might consider rebuilding on a good quality USB thumbdrive (such as SanDisk or Samsung). Preferably, the thumbdrive would be no larger than 32GB. The no name M.2 drives that comes with this model of mobo are of questionable quality.

    Where are you getting the following?

    I tried this earlier but that only removes the drive from the config for snapraid. It does not point to a empty directory, which is required as per

    Zitat

    To remove a data disk from the array do:

    Change in the configuration file the related "disk" option to point to an empty directory

    _________________________________________________________________________

    I tested the GUI remove process exactly as outlined above. Going further, I deleted all member drives to test the deletion of the entire SnapRAID array. There were no issues.

    If I were to speculate on what's gone wrong with your setup:
    You might have done something on the CLI that has created an inconsistency between the state of the array as known by the plugin and the array itself.

    In the GUI only:
    You might want to take note of the data drives and the parity drive as they are in the existing array, then delete the SnapRAID plugin. ((Take careful note of which drive is parity. If you set the wrong drive for parity, in the following, existing data may be erased.))
    Reboot.
    Reinstall the plugin and recreate the array, without the drive you're trying to remove. Obviously, run a sync after the array is setup.

    In the GUI:

    Under Services, SnapRAID, Drives

    Click on the (far right) Info Icon. From the pop-down menu select devices to match the SnapRAID drive name to the drive you want to remove /dev/sdc1

    Once you know which drive name to delete;

    Highlight the appropriate drive name, then click on the trashcan icon, and Save.

    Once that's done, run a sync command.

    While the drive will be out of the SnapRAID array, the existing data will still be on the drive.

    That's the way it works. However, when you create shared folders, you'll have to use the mergerfs mount point. If you set shared folders on individual drive filesystems, you're bypassing what MergerFS does.




    I assume MergerFS takes care when new folders/files are created based on the rules:

    Most Free Space

    Existing path - Most Free Space

    MergerFS is rules based. The two storage policies you mentioned above tend to be the most frequently used. You'll have to pick one. Most Free Space will balance out (to +/- 2%) over all drives. Existing path - Most Free Space can become unbalanced, for the reasons mentioned in the doc. (Usually related to video file storage.) However, the balance tool can straighten that out. Once the balance tool is used, generally, it won't be needed again.

    1. if the drive failing is the parity drive, I guess replace the parity drive and re-sync.
    2. Would Snapraid notify of a failure of the parity drive?
    3. or any drive in the pool?

    1. Yes. That's the solution. Replace the drive and sync. The parity drive is not protected but, if it's lost, the array's data is not affected.
    2. No. That's one of SnapRAID's weaknesses. (Nothing is perfect.) But there are ways to compensate, mentioned below.
    3. With designated data drives, yes. You'd start noticing miscellaneous file errors (which might be media errors) during a scrub.

    When considering the parity drive:
    Since parity is required for drive restoration, it's my opinion that the parity drive should be newest, healthiest, drive in the array.

    Part of overall drive management is activating -> SMART monitoring and testing. If you can, set up -> Server notifications for file system errors and SMART issues. (I say "if you can" because E-mail Notifications can be problematic with some E-mail providers.).

    Other maintenance items for consideration are covered in -> Utilities, Maintenance and Backup.

    But I'm confused as to how MergerFS and SnapRAID work together.

    They don't actually work together in a literal sense. One can be used without the other.

    MergerFS pools drives together, presenting them as a single mount point. SnapRAID protects drives, along with files and folders, using parity calculations stored on a parity drive. The parity calculation is done on demand (you initiate it). When the two packages are installed, together, they provide RAID5 like abilities without RAID5's down side. Further, with the potential to recover files and folders, and the ability to detect and correct bitrot, SnapRAID has features that traditional RAID can't provide.

    While written for OMV6, this documents -> MergerFS and -> SnapRAID will give you a better idea of what these packages do. Further, SnapRAID has extensive -> documentation at it's support website.

    SWDLD

    There's a lot of misunderstandings, out there, regarding the hacks. Generally speaking, where the criminal element is concerned, there has to be a "for profit" angle to motivate a breach. Beyond the considerable technical requirements; a "man in the middle" attack requires (1) that the target had been cased as financially worthwhile and (2) that an insertion point "in the middle" is possible. (The latter is not easy - data centers do not allow hacks to walk in, physically or virtually, and setup shop.) Both requirements mean that real prep work is involved so the payoff must be considerable. (As in far beyond what an end user or small business would be willing to pay.)

    For the home user or small business:
    One of the typical approaches for a payout would be ransomware where user data is encrypted and held hostage for money. Usually that's accomplished with "freeware", a nefarious E-mail link, etc. Usually, vulnerable users and their client PC's are compromised - not servers. Hackers are looking for "low hanging fruit". There are other methods but, generally speaking, the hacks get some sort of malware out in the wild or compromise a web site and hope for numerous compromises to make the relatively small payouts worthwhile.

    Large business and corporations are another matter altogether. They are targeted constantly but Corp's have staff that deals with their security issues.

    In any case, Linux is the most used server OS by a w-i-d-e margin, when compared to any other server OS. -> 2023 Server OS by market share. One of the main reasons is security. Given that Debian is one of the oldest and most conservative among the Linux distro's, you can feel pretty confident that the Debian package manager apt is pretty secure.

    In the bottom line, when it comes to your server's security:
    Apt is not the issue. You are probably the greatest threat to the security of your server. The hot second ports are opened to the internet, dockers are used, downloaders, other 3rd party packages are installed, etc., the security of your server is progressively degraded. I would worry less about the Linux OS, and it's ancillary packages, and worry more about what you plan to do with your server.

    First, I don't use the user home directories option.
    (When I created my own user setup, I created a SMB network share called "Users" , then I gave each user their own personal share under that folder that only they had access to.)

    Second, I don't believe that OMV would assign an ACL (as in automatically checking that ACL box). I would uncheck the box. Actual ACL's can cause all sorts of problems. Try to stick with Linux permissions as assigned to Owner, Group, Others


    Third, you're right in that if you change config files on the CLI, most of them get rewritten as the of the next on-demand configuration change made in the GUI.
    __________________________________________________________________________

    Given that I believe there's been a Samba security update recently AND you mentioned an android device, you might try the following:

    Under
    Services, SMB/CIFS, Settings

    Paste the following into Extra Options at the bottom:


    min protocol = SMB2

    max protocol = SMB2

    The username and password, used with Remote Mount, must have at least a minimum of read to the remote share. But, when it comes to Windows servers, a username and password that may not be enough.

    Windows servers, particularly when they're in a domain want to verify the user in Active Directory and that may mean that the device that is connecting the user (the Linux server) must be listed as a server or workstation device before access is granted. In a domain, the credential verification process is not as simple as just a username and password. -> Credentials in Windows.

    If the Linux server is outside of the Domain (which can mean outside of a certain IP-range or the server is not listed in AD) a username and password may not be enough.
    ________________________________________________________

    There may be a work around, if you look into it.

    - Add the Linux server to AD, as a workstation.

    - A hidden share at the Windows server is a possibility. I'm not sure how that would work within AD but it might bypass AD security while allowing you to specify single user access. In security, I would start with "Everyone", to see if it will work. If it does, lock it down from there.


    That fixed the Issue.

    thanks crashtest and Stryker

    For the best security, it would be best to go to the highest level possible. Since you're nailing down the protocol level, going with the highest that will work would allow for a bit of "future proofing".


    Currently, the highest protocol, that I'm aware of, is SMB3_11 (The Windows 10 variant.)

    If SMB3 will run, that's the Windows 8 variant, that's what I would use.

    - Set Shared Folders to Others Read,Write,Execute and Users to Read/Write/Execute (only my user has RWE, and i t worked for weeks)

    - Set SMB Shares to Read Only - Off and "Guests Allowed" (read only is off, but quests are not allowed)


    I'm surprised you haven't at least tried the above. From a permissions perspective, that's all I have for you.

    If you have something that "looks like a permissions problem" the first thing to do is open everything up:

    - Take notes on what you have.
    - Open permissions.


    If it works, go from there. If it doesn't work, nothing is lost.
    ____________________________________________________________

    You might give some thought to the previous post of Stryker . While it's nothing but speculation on my part, it's remotely possible that a SMB security update changed Samba's operation. Enabling a specific protocol level of NT1 or SMB2 might be worth looking at. This is another item that's easy to try and, if it doesn't work, it's easy to remove.

    To lock in a specific protocol level the following statements would be needed in SMB's extra options:

    min protocol = NT1

    max protocol = NT1


    (OR)

    min protocol = SMB2

    max protocol = SMB2

    when pushing files from my linux via FTP to the OMV some files got mangeld files names. so i put "mangeld names = no" into the smb options and it worked.

    First, it's best to pull files into OMV, using OMV. What is "my linux"? A host, a server?

    today i realized, that i cant access my shares from the LAN Tab in RS FileExplorer on my android.

    I can't speak to this. "My android" is probably a smart phone or a tablet. The security measures OEM's use to protect them are different among the various OEM's. They march to the beat of their own drum.

    and just wanted to restart the NAS but even the weblogin wasnt accepting my login. so i had to hard reboot.

    after that the weblogin was working, but i could not find any error. but i still could not connect the android app.

    You could have SSH'ed into your server (like you did with using omv-firstaid) and shut it down on the command line.

    Now i was afraid that non of my share would work, but my existing shares in Kodi and win11 are working without problems. but i cant connect newly created folders. nor add the old ones to other devices. only my printer tells me that he cant access the old folder. (folder corect, folder not write protected, ECODE: 0x0C002032, -29, STATUS_NOT_SUPPORTE

    I'm not sure what you're talking about; "folders"? Are you really talking about SMB shares? If you need a Shared Folder / SMB permissions primer, see -> this.

    The short cut is:
    - Set Shared Folders to Others Read,Write,Execute and Users to Read/Write/Execute
    - Set SMB Shares to Read Only - Off and "Guests Allowed"

    ________________________________________________________________________________________________


    The likely reason that no one answered your post is, it's a technical rabbit hole. You're talking about multiple clients, running differing OS platforms, push FTP files transfers and there's no way to know if you've introduced Linux permissions and / or created permissions conflicts by checking ACL boxes. Adding to that, you're using KODI (a media server), in some capacity, which introduces another set of factors. There are numerous details involved with your issue(s) and nowhere near enough information to even begin.

    The best that could be done, if someone is inclined to take this up, is to get your Windows box access to OMV's SMB shares.

    Since you have an R-PI, you also need to run the following script BEFORE attempting to make any network setting changes:

    wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/preinstall | sudo bash

    Running this script is a one time thing.
    _______________________________________________________

    If you ever have the occasion to rebuild your R-PI, follow the install procedure found -> here.