Beiträge von seed

seed · 3. März 2020

Zitat von Morlan

Check this out https://forum.openmediavault.o…V5-Pi4-This-might-fix-it/

This looks promising. Will give it a go. Thanks @morian

seed · 3. März 2020

Zitat von gderf

If you are using /sharedfolders/.......... paths in your docker Volume and Bind Mounts you are making a mistake. Use the actual location of the folders instead.

Sorta the point though shared folders. Why go digging for the srv disk ID really..... It's annoying. Why can't they just fix it so that docker spins up after the drives and sharedfolders routine is done...

@'wookash 'Go start a different thread please....

seed · 18. Februar 2020

So this seems to be the issue, docker starting before the sharedfolders are mounted:

Code

2020-02-17T22:05:22-0800 omv.humptydance.nope dockerd[721]: time="2020-02-17T22:05:22.517570335-08:00" level=info msg="Starting up"
2020-02-17T22:05:32-0800 omv.humptydance.nope systemd[1]: sharedfolders-apps.mount: Directory /sharedfolders/apps to mount over is not empty, mounting anyway.

seed · 18. Februar 2020

I use docker and portainer rather intensely on omv managing a bunch of crap. I structure most of the containers to have configs in one sharedfolder and content in another and map to those so really the only thing the container has locally is itself, so I can cycle em out and backup the configs and such to another storage on their own. This is helpful for plex cause it's a hog with its config dir so that goes on a faster drive separate from a larger media pool which is also on its own drive.

Anyway, the issue I'm having and this has surfaced a few times is that if the sharedfolders for whatever reason, maybe on boot? aren't available to the containers in time, the containers will write to the path /sharedfolders/stuff, and then even if the sharedfolders gets mounted right after, the app is writing underneath, then the disk fills up and OMV interface isn't accessible, and my / volume is full. Then I have to reboot, comment out the two drives that were mapped to these shares, delete the content that was written to the real / path on the local disk, and reboot the instance.

I'm not sure why in all the cases this has happened but I'm thinking maybe this isn't the best way, using sharedfolders, for docker like this but i'm not really sure about how to do this as an alternative. If I can mount a new disk somewhere else that guarantees it won't mount it if the disk isn't available, perhaps that's the right way, just not sure off the top of my head that's any different than what the shared folders is doing.

How do the sharedfolders map to the device? It seems like some hybrid between mounting and symlinking but i'm not familiar with how they work.

Maybe I should just write to the full /srv/dev-disk-xyz-0123 path?

Even in the time I wrote this, had to restart some containers after reboot, some of the underlying fs filled up"

before

Code

/dev/sda1          98730  5293     88404   6% /

a little later I think after I restarted the containers

Code

/dev/sda1          98730    74283     19414  80% /

Is there a way to delay the docker service from starting until the end of the boot up cycle?

seed · 12. Februar 2020

This is an issue with my VLAN routing for VMs vs HOSTS so my fault. Thank god.

Sorry baby. I didn't mean to threaten I was going to leave you. I'll take you to dinner.

Zitat von Seed

This might be a deal breaker for me at this stage.

seed · 12. Februar 2020

So I did a fresh install of debian 10 and OMV and have the same issue.

The board is x10sdv-tln4f
Ethernet Connection X552/X557-AT 10GBASE-T

Is this some incompatibility with debian?

seed · 12. Februar 2020

I just installed a new version of OMV next to an ubuntu VM fresh install 18.xx on the same proxmox host. They both use the same bridge. The new fresh OMV install refuses to run at 10Gb but the Ubuntu one works fine. Why can't OMV run at 10Gbit here? This might be a deal breaker for me at this stage.

seed · 12. Februar 2020

Hello,

I have a strange problem.

I installed OMV5 on a host that had a 1Gb adapter in a KVM host on top of proxmox. I have since migrated this VM to a new host which uses a bridge on a 10Gb card. The KVM image, however still runs at 1Gb. I installed a new KVM host using Ubuntu on the same host, bridge etc. etc.. and get 10Gb speeds but with this older omv host, it won't adapt. If I run ethtool i obviously don't get anything as it's a virtual adapter.

Any idea how I can reinstall the driver or get it set right?

seed · 13. November 2019

Is there anyway to mount remote NFS shares on OMV 5?

seed · 19. Oktober 2019

So I was able to get the array back but with only 5 drives. mdadm says it's clean but that isnt true as it should be 6 drives in the array. This was a major blow up and almost catastrophic as I was moving drives from the NAS to the new OMV arrays, where my backups were! oof.

Will save the data to another store and not try to add a new array with new disks on this setup until after it's offloaded to the NAS

seed · 19. Oktober 2019

Hello,

I had a RAID 6 array with 6 drives sd[bcdefg]

I added 3 drives and tried to create a new stripe to temporarily move the data too. When I tried to create a shared folder on the new striped array I got a huge error in the UI and everything took a crap. When I rebooted all raid volumes were gone, including the original good volume.

The filesystems are "missing"

For some reason md127 says it's now a raid0 array.

Examining the disks they are all RAID6 except sdg is RAID5 now? I have no idea why...

They say there are 5 raid devices, when there should be 6.

sdg seems to be royally borked and for some reason was used when I tried to create the new stripe.

root@omv:~# mdadm --examine /dev/sdb
/dev/sdb:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 519165ce:33fd48e1:1b948ddf:db836d5a
Name : omv:volume1
Creation Time : Sat Aug3 11:00:10 2019
Raid Level : raid6
Raid Devices : 5

Avail Dev Size : 19532611584 (9313.88 GiB 10000.70 GB)
Array Size : 29298917376 (27941.63 GiB 30002.09 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=0 sectors
State : clean
Device UUID : a2f6bbb2:9ee0f2ac:cd2d287d:ac583392

Internal Bitmap : 8 sectors from superblock
Update Time : Fri Oct 18 16:17:54 2019
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 856b67ab - correct
Events : 47453