Posts by Huberer

    Background: All was working fine on OMV regarding SMB files shares with both Mac (Monterey) and Windows 11 machines but for some unknown reason quit working on the Mac. The error on Mac was due to permissions and would not let me copy folders from the Mac to any OMV SMB share. It would however place a folder in the share like it wanted to copy but was empty and subsequently would not delete for the same permissions issue. Nonetheless, I was allowed to copy "files" over to OMV shares from the Mac and could delete them as well. But "folders" had the permission issues. After much testing and research into permissions tricks (non terminal) using the OMV GUI (i.e. reset perms), I could get the fold to copy once but after that the issue came back with the need to use reset perms again.

    Eventually, I removed all users from the OMV system and removed all SMB shares. I rebuilt the users and SMB file shares and all worked again. However, I knew there was one share that was allotted to the Time Machine support that would need to be enabled, so I enabled it and the problem came back exactly the same as before. Funny thing though is Time Machine had no problems running its backup to the shared SMB folder on OMV while this permissions thing was going on for everything else.

    So, I disable Time Machine support and all is working again but without Time Machine support. My assumption now is that Time Machine support for one of the SMB shares was enough to screw up all the permissions for the rest of the shared folder on OMV. I'm not sure why and would like to know if someone can help get Time Machine support to work without messing up the permission on all other SMB shares that are not touched by Time Machine? Do I turn on Time Machine support on all my SMB shares regardless of needing it for Time Machine (probably no?)? I have 10 other ways of backing up my Mac but Time Machine seems kind of cool and was working OK previously (seemingly nothing changed except one weird issue where I couldn't access the OMV GUI and had to reboot OMV from the console. After that seems like when the problem started).

    Thank you for this post. I had the same problem with my MacbookPro and Mac mini (both macOS Monterey installed). I couldn't copy any single file to the server because of "permission issues". I have searched the whole internet day by day to solve this matter. Yesterday I found your post and after disabling "Time Machine" on my OMV (v6) server, everything works like it should.

    Now I have to find out why? Why does "time machine" has such an impact at "write permissions" on the server?

    Is there anybody who has the same problem and could solve it?


    with the help of TechnoDadLife I've installed openvpn-as via docker to connect to my home server from outside.

    It's possible to have access to my home server (OMV v5) via the IP-address of the server. But I've some dockers running like PlexMediaServer (Port 32400) or TVHeadend (Port 9981).

    When I enter the IP-address of my home server, together with the port of PMS or TVH, in the browser of an Openvpn-client, I can't connect to these dockers. The IP-address, without any port, allows me to connect to the OMV-server.

    Now my question is, how can I have access to my dockers.

    Any help is appreciated

    Thanks in advance


    unfortunately there's something missing in the Virtualbox-Installation-Guide under OMV v5.

    The process of updating Virtualbox.

    I always got the error of still running VBoxSVC daemon therefore I couldn't update Virtualbox.

    1. Stop your VM's

    2. stop Virtualbox-services under CLI:

    sudo systemctl stop vboxweb-service
    sudo systemctl stop vboxdrv
    sudo systemctl stop vboxautostart-service

    3. Stop VBoxVSC daemon with:

    sudo killall VBoxSVC

    4. find and kill other process

    ps -A | grep VB
    sudo kill <pid>

    5. Update Virtualbox. I've downloaded the VB-package (.deb) and installed it via CLI

    dpkg -i virtualbox-6.1_6.1.x-xxx.deb

    With these steps I was able to update Virtualbox

    And to update the extension pack just follow the guide in the Guide-section by downloading

    cd ~/
    wget "link to the latest extension pack" (like today
    and with the command --replace you can update EP
    sudo VBoxManage extpack install --replace Oracle_VM_VirtualBox_Extension_Pack-6.1.10.vbox-extpack 

    after that I're rebooted my OMV-server and everything was up-to-date

    Thank you for this great info. Now I know why portainer is not working with the proxmox kernel.

    Maybe @votdev or @ryecoaaron know why AppArmor is not in the OMV installation iso but in the Debian iso.

    But according to this webside it's not recommended to disable AppArmor.

    Disable AppArmor
    AppArmor is a security mechanism and disabling it is not recommended. If you really need to disable AppArmor on your system:
    $ sudo mkdir -p /etc/default/grub.d
      | sudo tee /etc/default/grub.d/apparmor.cfg
    $ sudo update-grub
    $ sudo reboot

    At the moment I still use the stable kernel v4.19


    First of all I want to thank you for the real great VirtualBox-Guide here. It's a pity that VirtualBox is not anymore in the Debian 10 repo.
    With your how-to it was easy to install. Thanks again.

    There's still one issue I had.
    After I did all the steps in the guide I wanted to log in the web interface (IP-Server:8080) but neither with the vbox user nor with phpvirtualbox-webgui user I couldn't log in. I always got the info that user/password is incorrect.
    So I was looking around in the www and found a hint to use admin/admin for user/password. With that I could log into the GUI.

    Why it is like that? Did I something wrong or is this correct to use admin/admin.

    Till now I didn't have time to create a VM. First I want to be sure that the basic stuff is running without any issues.

    Thanks in advance

    This is a backports kernel (bpo). They were made available if the backports repo was enabled on OMV4, but IIRC, more recently they are used as the default. I'm on OMV5.

    Thanks for the info. So the last hour I did a fresh installation and it looks like that I've overseen the backport option under OMV v5. I've enabled it and now I run the backport kernel v5.4. And, can you imagine, portainer runs fine. So, there's is something with the proxmox kernel which hinders the installation of portainer.
    So the problem is solved for me. Thanks again

    Thanks. It looks that you're using the proxmox kernel.
    I really don't understand why is portainer working on some users with proxmox kernel and on three systems of mine (2 real machines and one VM) not. Really, really curious .....

    Do you use the proxmox-kernel? If yes, portainer is not working under this kernel. I’ve installed on three different machines the proxmox kernel and couldn‘t get portainer to run. On the standard Debian kernel everything runs fine.

    Gesendet von iPhone mit Tapatalk

    I know about TABs @macom ;) I work a lot with CLI :thumbup:
    But as I saw on different guides for docker-compose some are mixing the paths. Like /srv/dev-disk-by-label/xxx and /sharedfolders/xxx
    I read somewhere that paths with /srv/dev-xxx should be more stable than /sharedfolders/xxxx

    I know what symlinks are but didn't work with it. I also didn't know about the plugin (shame on me).

    What I do with my containers and compose-files is to copy them. So when I do a fresh installation, I create the same folder structure again under OMV. Put the compose-files to a special folder, run them to create the container. Stop the container, delete the new one and replace it with the backup. Of course I've to change permissions and owner. With that I don't face any problems.