Posts by miazza

    Fixed in openmediavault 6.0.39, see https://github.com/openmediava…bb95d932a6f74ec051b27fb90.

    This upgrade is still not available with omv-upgrade:

    update is available now

    Code
    via the CLI command 'omv-upgrade'

    and the issue is solved : after reboot FTP service is available.


    Now when I enter in dignastic for FTP service I get an error:

    Code
    Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; export LANGUAGE=; ftpdctl -s /run/proftpd/proftpd.sock ban info -v -e 2>&1' with exit code '1': no users connected ftpdctl: error contacting server using '/run/proftpd/proftpd.sock': No such file or directory

    diagnostic for smb and ssh is ok instead and all the rest looks ok.


    I seems that:

    Code
    /run/proftpd/proftpd.sock

    does not exists.


    Code
    root@debian:/run# ls
    .              blkmapd.pid      crond.reboot       faillock   lvm           mount            php                     rpc_pipefs      samba              sshd.pid    user
    ..             chrony           dbus               fsck       mdadm         mysqld           proftpd.ban.tab         rpcbind         sendsigs.omit.d    sudo        utmp
    agetty.reload  chrony-dhcp      dhclient.eth0.pid  initctl    minidlna      network          proftpd.pid             rpcbind.lock    shm                sysconfig   wsdd
    apache2        collectd.socket  dmeventd-client    initramfs  monit.pid     nginx.pid        proftpd.scoreboard      rpcbind.sock    snapd-snap.socket  systemd
    avahi-daemon   credentials      dmeventd-server    lock       monit.sock    ntp.conf.dhcp    proftpd.scoreboard.lck  rrdcached.pid   snapd.socket       tmpfiles.d
    blkid          crond.pid        esekeyd.pid        log        motd.dynamic  omv-engined.pid  redis                   rrdcached.sock  sshd               udev

    got same problem.


    omv-salt deploy run proftpd - solves the issue, but after OMV restart proftpd not launching again, so i`m thinking to add omv-salt deploy run proftpd in cron on @reboot

    This is not the right solution even if it should work in rc.local.

    There should be a config file on OMV that is not set correctly and at reboot this folder is not created.

    After having sent

    Code
    omv-salt deploy run proftpd

    the folder /run/proftpd is created but after reboot it is not anymore present:

    Code
    root@debian:/run# ls
    .              blkid            credentials        dmeventd-client  initramfs  minidlna      mysqld           php           rpcbind.sock     shm                sudo        user
    ..             blkmapd.pid      crond.pid          dmeventd-server  lock       monit.pid     network          redis         rrdcached.pid    snapd-snap.socket  sysconfig   utmp
    agetty.reload  chrony           crond.reboot       esekeyd.pid      log        monit.sock    nginx.pid        rpc_pipefs    rrdcached.sock   snapd.socket       systemd     wsdd
    apache2        chrony-dhcp      dbus               fsck             lvm        motd.dynamic  ntp.conf.dhcp    rpcbind       samba            sshd               tmpfiles.d
    avahi-daemon   collectd.socket  dhclient.eth0.pid  initctl          mdadm      mount         omv-engined.pid  rpcbind.lock  sendsigs.omit.d  sshd.pid           udev

    Yes, the file /srv/salt/omv/deploy/proftpd/default.sls exists:


    I do not understand why after reboot it is not available.

    My version is 6.0.37-1 (Shaitan).


    If I use that command FTP starts but if I reboot the problem is again there.


    The point here is that the path

    Code
    /run/proftpd/ban.tab

    is not existing in the system after reboot

    When I enable FTP from GUI, FTP works fine.

    When I reboot my Debian FTP is not anymoe started (RED in the table) and ProFTPD FTP Server fails to start;


    The problem is here since my first install and I need to restart manually every time.

    Do you have installed the flashmemory plug-in?

    If so, uninstall it and run


    # omv-salt deploy run proftpd

    Sorry for the late reply.

    I do not have flashmemory plug-in because my install is on armer architecture and omv-extras are not available.


    I only managed to install resetperms.


    I tried the above command and it has restored FTP service but after reboot I still have the same issue.

    I can enable FTP and have it working on a share but after reboot the service goes down and I cannot anumore connect.

    The share is still there and the service is marked as active but the diagnostic says:


    I tried several times but the result is always the same.

    You should not mess with ACLs or permissions on your share, as this will most likely break owncloud. Do not even use the resetperms plugin.

    This is why I recommend to use docker and not use a shared folder for addition software.

    I have realized this when it was too late and I lost my owncloud data.

    Now I have it working but this ACL is very scaring for me and I really would like to disable it from my share.

    Unlikely the tick on the ACL page seems not to work....

    Usually, whenever I change settings I have to confirm that afterwards to actually apply these changes. If I untick the box in the ACL menu not to replace the existing permission the system does not ask for approval after clicking on save - and indeed, it does not save the changes (when I return to the menu later the box is ticked again).

    I have the same problem here.

    I press SAVE and the green box appears but the apply changes is not asked.

    The SAVE button remains active and you can push it several times but the tick remains and the wanted configuration is not saved.

    Definitively I would like to disable ACL from my smb share but all the files are with + at the end.

    As long as you find your way around in your system ...

    I would not share the internals of the containers in samba, but everbody has its way

    I agree with what you say but here in my home the everybody it's me my wife and my kids and .the owncloud data is chmod 700 so from samba nobody can access that folder (not even me). If you try to clik on it you get the worning you not have permission.


    For the time being is seems a good compromise.


    I'm now wondering what will happen if I remove the ACL on that disk ... is there the risk to mess up owncloud ?


    I'm really scared by this ACL doing things alone and automatically.


    By the way, I am not usin docker and containers. They are living together in the same system.

    This path looks strage: /srv/nsa325/omv-nsa325/owncloud

    Why are you trying to place the ownclod directory into a smb share?


    I think you are mixing things up.

    I have only that disk. It is not accessible to the users but this is the only DISK I have.

    The fact that I am sharing it in samba shoud not do anything until I do not try to do something on the owncloud data folder.


    That path (omv-nsa325) is a link to the OMV mounting that is a long string that I cannot remember.

    If someone is interested, the owncloud permission and ownership is as below:

    How are you accessign the smb foolder now? The permissions will not allow group to see the files.

    Well, this is a kind of magic :) and I am sure it is a mess of chmod and chown I have run on the entire share from ssh in order to try to solve the issue.


    I go by hart because I'm not in front of the NAS bu I guess the owner of the Share is www-data (apache2).


    Now I have smb share \ that is accessible from windows to any user with 777 permission on all the subfolders (in systemd they are all green shadow). Only exception is the owncloud data folder that I have modified with chmod 700 as requested by the GUI at the first login after having created the data folder on the smb share.



    As said, for me it's a kind of magic but yesterday night everything was well working.


    My share is configured like this:


    Owner= www-data → Read/Write/Exe

    Group = user → Read/Write/Exe

    Others → Read/Write/Exe

    Then there is a flag on “replace all existing permission”.

    The flag “Apply permissions to files and subfolders” is not flagged.