Posts by gderf

    OMV 4 is end of life. This can make the availability of Debian updates difficult and the availability of OMV plugins impossible. It's just no longer supported, period.


    Start thinking about not avoiding docker. The number of OMV plugins gets smaller with each new release and dockers are the suggested way to replace plugins that have been deprecated and never to return.

    i did as tutorial said
    set UUID and GUID as i read in putty
    998 and 100

    Bad advice given in that tutorial when they say to use PUID=998. It makes every file your docker creates owned by the OMV admin user.


    Start learning the shell. This can not be stated often enough.

    i tried install transmission but i was stuck. I done all by portainer and when i try access it it says forbiden so i switched to qbitorrent
    its working now but im having problem i cant delete files in folders from my PC when i access over network, I can only delete them trough qbitorrent

    If you can't delete something over the network, the user attempting it does not have the write permission needed to do so.

    I used dd, but it's been so long if I told you what I did I'd probably be lying as it's been at least 5-6yrs ago. I wonder if by chance I didn't image my whole 64gig SSD, and that's why it was taking so long, vs just my root partition..

    Using dd to image the rootfs partition won't copy the boot track, so the restored image will not boot.


    There's a way to also use dd to grab that piece separately but I don't know what it is, never needed to do that. May also be a way to easily take that non-bootable rootfs partition restoration and clobber in a boot track.

    What did you use to image? I use this:


    Code
    now=$(date +"%Y.%m.%d.%H.%M.%S")
    file="omv-6-$now.img"
    dd if=/dev/disk/by-id/usb-PNY_USB_3.0_FD_070B67D5A4B2D178-0:0 of=$file bs=1M status=progress

    Prior to switching to a USB stick I used a 16GB 2.5 inch Samsung SSD in a USB case. That was considerably faster but all these times are so small to begin with they don't enter into the choice.

    I see a similar to your jbd2/sdc2-8 but it has no significant amount to it and the letters and numbers are different. Those are the disks or related to them. kworker is some sort of kernel task placeholder thing, google for more info. I see it too but with very little amounts.


    How much RAM in the machine and do you have swap enabled?

    Thank you wor your suggestion. I will use this. But anyway this is workaround / not a real solution. Just look what will happen if you will format your drive, or replace it. The uuid is a random number changed after every drive format. Then what? You have a lot of wrong entries @ your OMV system.

    Then what? You change the new filesystem UUID back to what it was before you formatted the drive. Unless you don't know what it was before. Would not knowing this be stupid?

    I've been with OMV since V2 and this feature has been frequently asked for, and most certainly been asked for well before ever I got here.


    I don't recall when I first read something from votdev I believe, that suggested that the feature was planned for a not too distant release.


    But we're all still waiting, most of us quite patiently and extremely thankful for what we have.


    The only way I could ever provide a real definitive answer with an actual date on it would to be able to offer my help by making what would have to be a very large and complex set of code contributions. I wish I could.


    In the meantime if you are properly protected with a known to be restorable backup of your OMV there is no reason to be a victim to a totally lost system. Even if you can't extract all the settings and import them to a fresh install, you can still get the same result with the restoration, even if you have no idea at all what the settings were.


    You can also use these backups to make a copy of your OMV to attempt an upgrade to the next release without actually risking your current running copy of the system. I do this and have never ever been a victim to a situation where I couldn't get back to exactly where I was yesterday, or up to seven days ago.


    As for what the settings are, you can read the config.xml file. Not the most user friendly view, but it's all there even if all you can do with it is look at it. Even if I didn't have an actual copy of that file all by itself I can extract it by hand from my dd backup images. I can extract the file from different daily backups and run diffs on them to see what changed day to day whether I made any changes or not.


    In the meantime, this strategy has amplified my patience in waiting for the feature we all want and need.

    Is there some reason you can't use what's already available that already works for this?


    With some images you can actually make up undocumented stuff so long as it strictly follows the conventions of what it would expect. You could always try and see. But this image is touchy all by itself anyway.


    Not sure what to expect with feature requests on this one. It has reported problems that have still not been fixed.

    should this work?

    /srv/dev-disk-by-uuid-c02f9840-5c78-47e3-9277-345213d858b3/TorrentZ_Uploads

    I added this in qbittorrent GUI:

    Automatically add torrents from: /downloads/TorrentZ_Uploads then selected monitired folder in the drop down.

    Most likely would not work.


    The container will only talk to a host filesystem directory identified via a volume bind mount and only through the container directory bound to that host side directory. I don't see this in what you show.