Posts by gderf

That looks OK to me. Did you try disabling swap temporarily as a quick test to see if it gets quiet?

Quote from Neocro

Sorry im total begginer in this. As now all i can do is follow tutorials nothing at the moment i can do different

Well, everyone was a beginner once. But you may find that this excuse might not hold up very long. Please start learning the shell.

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.

Check the permission and ownership of that directory in the shell and correct them if needed.

Quote from Neocro

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.

Use the shell in OMV to determine the permissions on folders you can not delete. Compare to others that you know you can delete.

So, what is the exact error you are getting, what tool are you using that gives the error to you, and how are you accessing the folders over the network - SMB/CIFS, NFS, or what?

Quote from Neocro

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.

Quote from KM0201

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.

Quote from mes mariusz

Also because there is no any support to export / import settings then if you need reinstall or switch to a other OMV release you need to do everything from the beginning.

As was explained to you you can protect yourself from this. But if you insist on doing things the hard way, knock yourself out.

Swap is enabled by default. It's possible you are hitting it. Try disabling it and see if it quites down.

https://www.computerhope.com/unix/swapon.htm

Quote from Nabukodonosor

8GB of ram. No swap.

That should be OK so long as you don't have a lot of unexplained crashes that could be caused by running out of RAM. I run with 16GB and no swap and it's solid.

No swap means no disk access caused by swapping. Do you have swap capability and it's disabled, or does the capability not exist at all?

What did you use to image? I use this:

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.

My dd OMV system drive backup images (16GB USB 3.0 stick) are done on cron so how slow or fast this is doesn't matter to me, but it's under seven minutes.

A restore to bare metal using a proper USB 3.0 stick takes under fifteen minutes but I don't recall the exact figure.

Quote from Soma

Read this a bit on the diagonal, but just some thoughts on 2 points (this is on linuxserver/docker-qbittorrent so it works on mcnugem's) :

1. The WebUI port can be change to whatever you want, if you use the YML/stack with, for eg:

Code

- WEBUI_PORT_ENV=40000 #the port number you want to access the WebGUI
....
ports:
- xxxx:40000 # xxxx the port you want to expose on the Host : The port selected for WEBUI

Please see this:

https://github.com/MarkusMcNug…-qBittorrentvpn/issues/97

As for the watch folder, your suggestion is worth a try. I use it the way it already is because I had no need to change it.

Display More

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?

Quote from mes mariusz

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.

Quote from HackitZ

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.