Cloudcommander has no acces to files to external HDD - Docker

1st Official Post

    I have installed Cloudcommander as the first Docker container via OMV7 Compose settings. This is accessible. I can see and click on all the files on the NAS. If I want to copy new data to the NAS, I use an external hard drive that is mounted first.


    I have reinstalled OMV7 and applied the system settings with omv-regen. I had previously created the Docker containers with Portainer and then accessed them. Now I wanted to use the variant in OMV7, which I find quite good.


    However, I can no longer access the data on the external hard drive. Normally I use the root directory in the right-hand Cloudcommander window and then srv and then select the files on the external hard drive. But I can't see anything under root. The directory is empty.


    It is not the root user who has access to it, but the user ‘docker’. Is it due to the access rights in OMV or the share folder?


    I hope anybody can help me.

    Update info:

    What have I done so far? I have created the Docker, Docker-Compose and Docker-Backup folders and assigned the rights to the root user.


    Then I installed my Cloudcommander Docker container via the Compose interface in OMV. I then opened it and checked whether I could access the previously mounted external hard drive. This is not yet the case.


    Now I have installed Portainer via the OMV Compose interface as an experiment. I have also installed the Cloudcommander container in it. Of course, this was stopped by me in OMV. After I then accessed Cloudcommander, I was also able to access the data on the external hard drive under ‘root’.


    So apparently Portainer creates the containers with root rights and OMV-Compose does not? What could be wrong in OMV as access is not working?


    Perhaps someone can help, as I would now like to use the container management via the OMV interface.

    Quote from macom

    Post the compose file you are using in OMV.

    This volume statement is invalid:


    Code
    - /srv/dev-disk-by-uuid-c4d926b1-f718-4809-8199-7dcda4faa39a:/srv/dev-disk-by-uuid-c4d926b1-f718-4809-8199-7dcda4faa39a

    --
    Google is your friend and Bob's your uncle!


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.


    Quote from gderf

    This volume statement is invalid:


    Code
    - /srv/dev-disk-by-uuid-c4d926b1-f718-4809-8199-7dcda4faa39a:/srv/dev-disk-by-uuid-c4d926b1-f718-4809-8199-7dcda4faa39a

    Could you please explain your statement, so I can understand it in the right way?

    To the left side of the colon is the identifier for the host side location. To the right side of the colon is the inside the container location. You can not use host side identifiers inside a container.

    --
    Google is your friend and Bob's your uncle!


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.


    And having the / FS binded, that folder is already visible inside the container.

    I have edited the compose file. Now the disks of the NAS are mounted at ‘/mnt/fs1’. The external hard drive is mounted at ‘/mnt/fs2’. Maybe there is a more elegant solution?


    Code
    services:
web:
ports:
- 7000:8000
volumes:
- ~:/root # Access to the home directory of the host
- /srv/dev-disk-by-uuid-c4d926b1-f718-4809-8199-7dcda4faa39a:/mnt/fs1 # Mount for the first hard drive
- /srv/dev-disk-by-uuid-12F4-2F22:/mnt/fs2 # Mount for the second hard drive
image: coderaiser/cloudcmd
restart: unless-stopped

    Based on the second drive uuid, it is not a Linux filesystem. That could be the problem. Using non-Linux filesystem can cause all kinds of problems, particularly with network shares and docker, because they don’t carry Linux ownership and permissions. They should only be used as a “transport drive” to copy to/from an attached Linux filesystem.

    You can do as I said. Don’t use a non-Linux filesystem for anything that is permanently connected to the system.


    That means either reformatting the drive in omv if it is empty, using a different drive that is Linux formatted and copying the data onto it, or copying the data to a temporary location, reformatting the drive into a Linux filesystem and copying the data back.

    Quote from wmcig

    Ok. What can I do? I need help to make it better.

    If you just want to use the YML to access the system with USER root to have full access to everything, use this:

    Code
    services:
  web:
    ports:
      - 7000:8000
    volumes:
      - /:/mnt/fs
    image: coderaiser/cloudcmd


    The above will launch the container with the HOST root ( / ) FS binded to /mnt/fs inside cloudcommander.


    If you want to see the drives of the host, you follow the links, inside the commander by going down:

    Code
    /mnt
|->fs
   |->srv
      |->dev-disk-by-uuid-c4d926b1-f718-4809-8199-7dcda4faa39a
      |->dev-disk-by-uuid-12F4-2F22
|->fs
   |->home

etc....


    Since it's ran as root and you have access to everything (even foreign FS like NTFS OR exFAT/FAT32) , you can KILL your system with a bad command.

    Be sure to know EXACTLY what you are doing.

    Quote from BernH

    They should only be used as a “transport drive” to copy to/from an attached Linux filesystem.

    I only want to use the external drive to transport data temporary, after I mounted the external storage. The external storage will be not mounted permanently.

    Quote from wmcig

    I only want to use the external drive to transport data temporary, after I mounted the external storage. The external storage will be not mounted permanently.

    Then I would suggest using rsync to copy the data but you will likely have permissions issues since ntfs is only accessible as the root user, or better yet, to avoid permissions issues, copy it across your network to a samba share. The files will then inherit the owner.permissions of the user that is connecting to the share.

  • wmcig

    Added the Label resolved

Participate now!

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

Register Yourself Login