SMB will not start

  • I've been struggling with one problem after another after installing updates this morning. All that was updated were docker packages, but afterward I first couldn't get into my web admin (since resolved), and now I can't get Samba to start. Help would be much appreciated.

    On attempting to apply configuration changes through the web admin, I get:

    When I run "systemctl status smbd.service" followed by "journalctl -xe" in the shell, I get:


    Please help me get my shares back up and running. Thanks!

  • I should add that a bunch of permissions got messed up somehow by the docker updates install, so fixing some of the stuff I was able to fix myself involved reclaiming root ownership of a bunch of different files. I suspect there may be more permissions to fix somewhere. I just don't know where.

  • UPDATE: I got Samba working again. My myriad problems were caused by ownership of many directories and files being updated after updating docker packages (through the OMV admin). That's never happened before. I don't think all my issues are resolved yet, but setting root:root as the owner of nearly everything on the boot drive resolved the Samba issue for me.
    One thing that wasn't fully resolved was the 502 error when trying to login to the admin. To fix that, I once again had to run:


    mkdir /run/php
    chown www-data:www-data /run/php
    chmod 755 /run/php
    omv-salt deploy run phpfpm
    Any reason why that fix doesn't seem to stick?

  • I found that ownership of nearly everything on my boot drive had been updated to the wrong user and group. I fixed most of my issues by resetting the ownership of most folders recursively on my boot drive to root:root. Just be careful not to reset ownership of everything under /srv/ where your non-boot filesystems are mapped.

    ex: chown -R root:root /etc/

    • Official Post

    I fixed most of my issues by resetting the ownership of most folders recursively on my boot drive to root:root.

    ummm... Is it possible that this will give you problems in the future? I would use omv-regen to move the configuration to a clean system.

    • Official Post

    And I would also make sure to replicate the permissions of the files that omv-regen copies to the new system before regenerating. You have the list of files here. https://github.com/xhente/omv-…ster/omv-regen.sh#L69-L75

  • ummm... Is it possible that this will give you problems in the future? I would use omv-regen to move the configuration to a clean system.

    IS it possible this will give me problems in the future? How would running omv-regen help here?

  • I found that ownership of nearly everything on my boot drive had been updated to the wrong user and group. I fixed most of my issues by resetting the ownership of most folders recursively on my boot drive to root:root.


    ex: chown -R root:root /etc/

    Please, don't advertise this anywhere and to noone.

    This is BS.


    Your system is FUBAR and you need to do a fresh install to fix that.

    • Official Post

    IS it possible this will give me problems in the future?

    I would not trust a system in which the permissions and/or owners have been completely modified.

    How would running omv-regen help here?

    omv-regen moves your OMV configuration to a new, freshly installed system. Files and directories will have the appropriate permissions.

    You just have to compare and make sure that the permissions of that small list of files that omv-regen copies are correct, the list that I gave you before.

  • Please, don't advertise this anywhere and to noone.

    This is BS.


    Your system is FUBAR and you need to do a fresh install to fix that.

    Could not have said it better myself.

    Linux Mint 22, openSUSE, Arch Linux

    OMV7 NAS 10GB Fiber, Fractal Design Define R5 Case, Kodi "Omega", FreeBSD pfSense Plus firewall/router

    • Official Post

    This is the list of files that you should check if the permissions and owners are correct. It is the only thing that omv-regen copies to the new system by default.


    /etc/passwd

    /etc/shadow

    /etc/group

    /etc/subuid

    /etc/subgid

    /var/lib/samba/private/passdb.tdb

    /etc/default/openmediavault


    If you have openmediavault-kvm installed, these two folders and all their content will also be copied. In that case the topic would be more complicated, that content can be extensive.


    /etc/libvirt

    /var/lib/libvirt


    If you add an optional folder to the backup, that folder will also be copied to the new system. In that case, you must also check the permissions of the files included in that folder.

  • etc/shadow

    At least this one I'm certain that it doesn't have root:root ownership


    As for permissions, who knows...

    • Official Post

    Please, don't advertise this anywhere and to noone.

    This is BS.


    Your system is FUBAR and you need to do a fresh install to fix that.

    I didn't mean to say it that way because over time I learned that it creates problems for me with some users... let's say... a little sensitive ^^

    But yes, that is exactly the situation in this case. :thumbup:

  • because over time I learned that it creates problems for me with some users... let's say... a little sensitive ^^

    That's why i'm not a Moderator, ^^

  • Please, don't advertise this anywhere and to noone.

    This is BS.


    Your system is FUBAR and you need to do a fresh install to fix that.

    This is not a usage of FUBAR I'm familiar with, given the system's been running fine for a few days now. ;)
    If it were truly FUBAR and I needed a fresh install, I don't think I'd install the same system that f'd it up in the first place.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!