votdev Not a nightmare but sometimes things do not work due to old adjustments.
Francobritannique Did you ever touch the etc/nsmb.conf file on your Mac in the past?! If so, maybe copy its content, save it somewhere as a text file for later and then delete it. Reboot. Reconnect the samba shares.
macOS requires SMB 3 protocol strictly and if you changed that file in the past it might be the culprit.
I don’t have any issues with Samba and macOS 14.1. Could you describe how you connect to your server?
Hitting CMD + K and enter SMB://ipofserver and then putting in your credentials?
Do you see the samba share in the finder at all?
As other machines are finding the share and be able to access it without issues I do believe it is setup properly but we have to find out what you might changed for the access of your MacBook to the share
Scheduling a task in the OMV GUI that executes the omv-regen backup command is very simple
Sometimes I am really missing the plot. Of course that’s the easiest way to schedule it with the command only 
Come decía Cerati: Gracias totales!
Thank you for this one... Just two things:
So the backup process has changed, right? Instead of the files and folders I do now find two tar.gz files that are used to regenerate the machine if set up new.
And: I did set up a scheduled task for copying the files "the old way". In the new GUI I did not find any possibility to set up a new scheduled task with the changed parameters. No big thing to me as I will then once in a while just use omv-regen and do the backup manually but I just wanted to be sure 
Thanks for the great work.
I just wanted to shout out a big THANK YOU to all of you folks who are steadily involved with OMV and its development and the tireless support you give here every each of us in the Forum. It's just incredible...
So, even if I did not want to name a few because I certainly will forget very important team members as well, I cannot resist (and sorry for forgetting some but maybe I get some help here, too):
ryecoaaron votdev Soma chente macom gderf KM0201 Spy Alelo crashtest donh subzero79 WastlJ Agricola
The compose-Plugin rocks, I finally could get rid of portainer and the docker management - at least in my case - is way easier and more stable.
And for those users who are unaware of the donation page, here is the link again: https://www.openmediavault.org/donate.html
Thanks again for all your efforts.
SSD's are in another category, when compared to spinning drives. In comparison, SSD's are super power efficient.
Yes, I just wanted to point out that sometimes it depends on the setup itself... that's all
I'd say: it depends. I have a low power NAS in the office and when I am longer than 6 hours not using them the harddrives do spin down. I also have a SSD in the NAS as principal hdd therefore it happens that the disks are not spun up sometimes even for two weeks.
Some of my disks are older than five years and work flawless. At least from the specs of the disk wear leveling should not be an issue but I do know that a lot of people do let their disks spinning even when not accessed.
MarcS do you have the pooled hdds encrypted? In my case after a reboot I have to decrypt, restart mergerfs, restart docker and everything is working as expected again.
docker stop container_name
Jep, that's what I did in the meantime... 
Is there a reason you need them all in one stack/compose file? Having them separate, also makes them easier to update, as you don't have to redeploy the entire compose file, just to update one container.
... but as it is sometimes just nice to use the GUI I will split the stacks now and have everything within one tab.
I was pretty heavily in stacks.. but they were super easy to move to the new plugin. I like it.
I am kind of the same especially it is easier to map the ports when adding services that depend on a different service.
So far everything is running, just one thing: If I want to stop a container I have to go to files and press the down arrow. As I have made various containers with one single stack I can only stop all containers. It would be handy indeed to be able to stop only a desired container instead of stopping all of them. Is there a way? If not, I would most probably split the compose files in order to be able to start and stop specific containers...
Otherwise: Great job ryecoaaron. Works flawless.
I just did the following steps and it fixed it:
Codesudo apt install apparmor -y sudo service apparmor restart sudo service docker restart
Just one question, maybe ryecoaaron can answer: I read a lot about not installing apparmor package is not recommended with a OMV install. I see a lot of users installed it and they are happy that their docker containers work again - and they don't complain about further issues (at least I could not find it). Is there any good reason to avoid installing apparmor if it does the job? Securitywise for example? Is it more likely to break the docker install done via OMV?
encrypting the system disk actually helps because nothing starts until it is decrypted. And usually the system disk and data disk get decrypted at same time avoiding the issue. When you don't encrypt the system disk, it fully boots and won't wait forever for the data disks to be decrypted. When this happens, services try to start but their data filesystems are not there. There are many, many threads about this on the forum. This is by no means a rare problem.
I second that. But I don't see that this is indeed "a problem". I repeat myself: If you do need encryption, encrypt. Of course encryption comes with the cost of having to put a little bit of effort once your machine is booting up - for me that is a non issue and doesn't take too much time at all:
- (Re-)Boot the machine
- decrypt the disks
- restart mergerfs
- restart docker
Either done via the GUI or CLI and it takes not more than 2 minutes.
Overall I am happy with the performance on my system. Via WiFi I get around 45MB/s and with LAN connected it doubles the speed of the reads. Writes only differ marginally but that's absolute fine for me.
Just a quick response: The "regular" / manual restore without the scrip has worked flawlessly for me. It's the most convenient way in order to get OMV up and running with the latest config changes. I do have clones of the sdcard though but as I am doing this procedure always on a different machine I would have to shutdown the NAS what I am trying to avoid. Really nice work.
Maybe I will also have a look into the script later on but for now it is as easy as it need to be for my needs
Well, putting the performance aspect aside: Do you need the encryption? That's the only question you have to answer regardless of the performance. If you need it, encrypt the data drives. If not, don't.
My use case: I have the NAS at the office and I do encrypt my drives as it contains also sensitive data that should not swirl around once the machine maybe got stolen and the harddrives are read / sold / whatever.
I can live with the performance loss but would also think it is not huge. Maybe different once another nas hardware will get in here, but hopefully not as I will also encrypt the drives
Thanks for clearing that out.
What kernel did you hold? If it was a backports kernel, then you need to hold two packages - the versioned kernel package and the linux-image-amd-64 package.
I put these packages on hold:
armbian-bsp-cli-helios64
armbian-firmware
linux-dtb-current-rockchip64
linux-image-current-rockchip64
linux-u-boot-helios64-current
Just checked this morning within the OMV gui and also the former kernel updates vanished - which is great. Ran the most current update via cli and indeed did not touch kernel or firmware.
So that's great news, bit strange though that it did upgrade yesterday via the cli... Anyhow: works 
Okay. Does that also include the omv-upgrade command executed via cli? Because I did hold the kernel (showhold shows the entries accordingly) but somehow the machine did update to the latest kernel.
Sorry for these noob questions but I thought: once I mark them hold that either way it is impossible to update to the latest firmware and kernel.
Old thread, I know, but I was running into a similar "issue": when putting the kernel and firmware on hold in order to prevent future updates OMV tells me nontheless that there are indeed updates. As I am no longer able to tick which update I wanna get within the GUI I suppose I have to do future updates manually over the cli in order to prevent OMV to also install the kernel updates, right?
Or is there a possibility to still use the GUI for updates but current firmware and kernel remain untouched?!
Just read and follow the post above yours
Yes, I found the docs of course. I can list all the variables and the current values, but not the original value... Or maybe I am just blind...
Question: Is there a list where all the environmental variables are shown with its original values?
I have set different variables for samba shares and I try to revert some of them but did not pay attention what the original value was. Any hints where I can find that?
