Posts by GuyFromMars

    I think the omv-aptclean fixed it because it says 5.5 is a candidate. If it still won't install, apt-mark unhold linux-image-amd64 should do it.

    Sadly, still a problem.

    Code
    sudo apt upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages have been kept back: linux-image-amd64 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.sudo apt upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages have been kept back: linux-image-amd64 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
    Code
    sudo apt-cache policy linux-image-amd64
    linux-image-amd64:
    Installed: 4.19+105+deb10u4
    Candidate: 5.5.17-1~bpo10+1
    Version table:
    5.5.17-1~bpo10+1 500
    100 http://httpredir.debian.org/debian buster-backports/main amd64 Packages
    *** 4.19+105+deb10u4 500
    500 http://deb.debian.org/debian buster/main amd64 Packages
    100 /var/lib/dpkg/status

    I just reinstalled OMV5 & omv-extras, enabled backports from web ui & now apt upgrade gives me the following:

    Code
    The following packages have been kept back: linux-image-amd64 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.The following packages have been kept back: linux-image-amd64 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

    How do I troubleshoot. Preliminary googling shows nothing useful.

    macom I intentionally want to stay on this thread for less confusion, so others can get a concise explanation for this change. gderf are the "problems" you were referring to discussed in this thread?

    If I understand correctly, this change means that a shared folder is created, but it's just under /srv/storage-drive-ugly-name/<sharedfoldername> now as opposed to under /sharedfolders/?


    Moving forward, how should we be handling shared folders as best practice? TechnoDadLife are you able to chime in on this?

    Lets keep the discussion in this thread. I know there are other people who will be confused by this, especially since a lot of people rely on tutorials from TechnoDadLife . Clarifying this for myself will help many other users. I use OMV as simple was to share files on my local network. My understanding is that, in order to do that, you have to mount given data drives, create sharedfolders and add them via NFS or SMB/CIFS in the OMV web GUI. Since I run OMV alongside a desktop environment, I would navigate to /sharedfolders/ and that same path is what is referenced in my docker-compose file. Now with disabling the "/sharefolders/" feature, I'm lost on what I am suppose to do now. Can someone explain exactly what problems "sharedfolders" creates and what method we should use instead? What are Symlinks?

    Sorry gderf, that didn't answer any of my questions at all. Per the changelog:

    Quote

    * Disable the '/sharedfolder/<xyz>' feature by default on new installations because it makes too much problems. It can be enabled by setting the environment variable to 'OMV_SHAREDFOLDERS_DIR_ENABLED="YES"'. Finally run the command 'omv-salt stage run prepare' to apply the modified default values and 'omv-salt deploy run systemd' to create the unit files.

    If the feature is disabled, what happens when I go into the "Shared Folders" section and create a shared folder? ...currently, without creating a shared folder in the GUI, the NFS option has no "shared folder" to share when I try to add one. The same is true when trying to share a folder via the SMB/CIFS option. Also, what are the problems?

    I'm really confused. How are we suppose to utilize SMB/CIFS and NFS with Sharedfolders disabled? And what trouble does leaving that feature enabled create? I read that it slows down the "apply changes" part, anything else?

    To answer your last question, no, I do not understand how a lot of this works, although I've tried to understand. I do not know which user is running the docker containers. However, now Nextcloud seems to be behaving itself. Maybe I needed to chmod and chown and then stop and restart container? Maybe I needed to occ files:scan --all after I did the chmod and chown, then restart the docker instance?

    No, I'm unable to access the Nextcloud data folder from the user I specified via GUID & PGID (outside the docker instance), so I assumed that I would have to make all these changes from within the Nextcloud instance, to keep everything working correctly. However, because I prefer a GUI, I did run Dolphin as root to bulk move data.


    Side-note, this does illustrate how I don't quite grasp Linux permissions. I'm not sure what I should run as root, what I shouldn't. If I should create a non-root admin account with sudo privileges, and keep my user account separate from the admin account with sudo privileges. However, my first goal was to get nextcloud and some other docker images up and running, then determine how to harden security later, as I've kept everything in my local network, thus far.