Beiträge von MarcS

  • OMV shared folder permissions

    I am having trouble with OMV folder permissions on a filesystem created by Synology.

    OMV can mount and see everything fine but when I create Shared Folders + SMBs , the permissions don't allow for write access from a remote host.

    Only after I run chmod 02775 on Foldername, the respective SMB becomes writeable.


    Why is that? Do I have to manually run chmod on every folder I want to share? I thought creating a shared folder takes care of that.

    This is the setup:

    OMV1---Folder1 (shared folder)----SMB---+++++++++++---OMV2

  • rootfs matches resource limit

    Zitat von ryecoaaron

    Use this instead: du -d1 -h -x /var/ | sort -h (the -x will not check the space of other filesystems). A quick look of your other output tells me it is mostly in /var though. Probably logs, docker, or plex.

    thanks. This command saved my day. I had my 32GB root fs at 99% !! Nervous .....:)

  • Linux Raid1 to Raid5

    I have a NAS with 2 disks in Raid1 full of data.

    Has anyone managed to migrate a Linux Raid1 to a Raid5 setup by adding 1 disk, while the data on the 2 original disks is retained? Theoretical this should be no problem but the internet is somewhat inconclusive so I was wondering if anyone has actually done it and all data was intact.

    thanks!

  • Migrate OMV to new platform

    as far as I understood the debian text Avahi provides hostnames independentent of any DNS service. So it could be cresting errors when Regen forces it to name the new host (using the same hostname) while the old host is still connected on the network. This was my case. The old host remains on the network.

  • Chosing filesystem

    BTRFS is great in RAID1 as it is stable and can easily be expanded later if you want to use bigger disks.

    ZFS in RAID5 is super stable and easy to recover. But in day to day running it has a lot of overhead so if performance is key then its not the 1st choice although you can improve speed a bit by adding SSD cache.

    Ext4/Xfs + Mdadm is stable in all Raid configurations but doesnt have the newer filesystem features like Snapshots, Scrubbing and Wow to prevent bit rot (as BTRFS and ZFS do have).

    So like everything in life its a trade off.

  • Migrate OMV to new platform

    OK. So all Docker Containers up and working.

    I must say I am very impressed by OMV-Regen. It saved me a ton of time and did 90% of the work automated. A big thank you for putting this together !! A massive tool.

    I will monitor my system but so far all seems stable. Maybe the network thing needs some looking at but considering that I am running an email-server and so far it works fine after the migration, its pretty great.

  • Migrate OMV to new platform

    Zitat von chente

    The only thing that omv-regen does not configure if you select not to configure the network is interfaces

    Ah I see. I think things like the host name should also not be configured if network is de-selected.

    There was def a network issue as I could not reset the interface or get an IP via omv_firstaid.


    Maybe when you have time and have an idea where I could reset or re-test this avahi module. I am not knowledgeable about this.

  • Migrate OMV to new platform

    Phase 7: here are some errors

  • Migrate OMV to new platform

    OK. I managed to reboot after which the drives unlocked and Shared_Folders are all listed. I haven't tested anything yet but at least Shared_folders are in the database.

    I managed to fix the network issue manually. I still think there is a bug inside OMV-regen as it should have not configure my network.


    All seems to be there now apart from Docker containers: Since migrated the server from ARM->X86, the containers wont come up. I guess I need to recreate them all....


    Still testing stuff and working on Docker but yes the LUKS needs a reboot prior to OMV-Reconfig doing all the mounting work.

  • Migrate OMV to new platform

    Unfortunately it didn't work. I think there were 2 issues:


    1) LUKS: omv-regen is trying to mount stuff when the disks are still locked. Crypttab was copied over but it needs a reboot for the unlock to be activated. Can omv-regen reboot and continue its process?


    2) Network setup issue: omv-regen did a full Network re-configuration although I specifically de-selected network configuration. I suddenly saw all the Docker networks on the host and could not get a host ip address.


    That screwed the entire system up and the network could not be reset with omv-firstaid.

  • Migrate OMV to new platform

    Crypttab

    Zitat von chente

    If I understand correctly the third field of the crypttab file is always the path of the file with the key. This is so?

    If this is true I can solve it easily. I would simply have omv-regen copy those files to the backup and then to the new system in the original path.


    Edit: The problem would be if there is a route with spaces. I understand when ryecoaaron complains about this.

    yes exactly.

    copy crypttab

    copy each key to the same folder as in old crypttab

    you also need to allow for change of disk order because this can change in the new system

  • Migrate OMV to new platform

    Here is an example of the crypttab format. You can have a separate key for each disk or one key for all disks.

    Code
    # <target name> <source device>         <key file>      <options>
sda-crypt UUID=xxxxxx                    /PATH/key1 luks
sdb-crypt UUID=xxxxxx                    /PATH/key2 luks

    The UUID is the unencrypted name of the disk. Thats what is later mounted and used by OMV and shown under /srv