ryecoaaron official fix on page 1 worked for me on my OMV6 running as a VM on Proxmox. Waited over a week to apply though just in case other solutions surfaced.
My Steps were:
1) Ran a Proxmox backup of the VM first
2) Copy and pasted the fix into putty
3) Applied the updates in OMV webgui, and rebooted.
Everything came back up as normal and no issues accessing Portainer.
I'm running on an AMD Ryzen 5900x in case that matters to anyone.
Yeah I see what you mean. The link doesn't seem to work anymore. I installed it to my emmc but it wasn't new or anything so I dont think that matters. All I did was follow the guide but unfortunately it doesn't seem to work right now. Hopefully the admin can correct it soon.
I used this script to install on my RockPro64.
It's probably not going to happen. If it will, the plugin maintainer has stated he will write a plugin to support other standard file systems.
Hope you are correct. It would be a really long process to upgrade in the future otherwise.
Ext4 here as well. I have read somewhere that omv6 will be using btrfs so if that's true then perhaps you should take that into consideration.
Finally got it working. As with the reference above there is a fix for 3 different files which are permission based. Please reference the link above for the fix of each file, I've included the location of the files below. Once the files are updated then delete the container, not the volume or image, and restart the container as mentioned in the @TechnoDadLife video or the nextcloudpi website. Hopefully this will help others until the docker image is updated with the fix.
File locations:
/ncdata/bin/ncp-provisioning.sh
/ncdata/bin/ncp/CONFIG/nc-limits.sh
/ncdata/etc/services-enabled.d/020nextcloud
liquidJiggy,
I'm having the exact same issue as you using my RockPro64. I clicked on the link that you had on the previous post which brought me to the GitHub page. Looked around but not finding exactly what to do to fix this redis issue. Would you mind giving a newb like me some more direction?
Would you fellas mind posting a pic of how to hack the cable to be used with the mean well power supply. I would love to get rid of all my little power bricks and just use something like this.
I am not using the /sharedfolders path anymore. I did initially after following tutorials from TechnoDadLife but stopped after the previous 2 OMV updates where I learned that it was being disabled by default or something to that effect. This is what I am currently using for my volumes setup. Only the appdata is stored on root:
https://drive.google.com/open?…_BEg05MeVzhXjbDhnmZAtvEf2
**update**
I have now setup an appdata folder on disk3 and was able to successfully transfer all the settings from plex, sonarr, radarr, lidarr, and lazylibrarian.
gderf, I do need to ask though why is it a bad idea to have the config files located on the shared folder created with unionfs? The benefit from what I can tell in doing so would be that I don't have to worry about any particular disk running out of storage as it will span any drive with the most available space on it. Still an extreme newb on all of this so looking to learn.
I too am having a similar issue like becksworth. I have my appdata on the root drive currently since it would not work on the shared drive created with unionfs, at least not for plex, sonarr, radarr, and lidarr. The movies and tvshows directories along with other dockers such as jacket, jdownloader, mylar, and qbittorrent work fine in the appdata fodler created with unionfs but not the appdata for plex and a few others for some reason. I will have to move the config for plex from my root drive to one of the data disks since it is getting quite big and will eventually fill it up.
Anyone know why this is or how to fix?
