FUSE Support and build.sh cleanup

[Ranbato]

@sdub76 please take a look and verify that it works for you.

[Sdub76]

I tried it and I can execute the mount command from the GUI and it says it successfuly mounted, but the folder is inaccessible from the docker container (docker exec -it vorta /bin/bash). Nor can I mount it to a folder that's mapped into the docker image. (Not sure if that could possibly work anyway).

ls: ./vorta_mount: Permission denied I have privleged mode turned on, and all of the extra options pased.

docker run -d --name='vorta' --net='bridge' --privileged=true -e TZ="America/New_York" -e HOST_OS="Unraid" -e 'TZ'='America/New_York' -p '5811:5800/tcp' -v '/mnt/user/appdata/vorta-docker':'/config':'rw' -v '/mnt/user/':'/data':'ro' -v '/mnt/disks/borg_backup/':'/destination':'rw' -v '/mnt/user/downloads/vorta_mount':'/mnt/vorta_mount':'rw' --device='/dev/fuse' --cap-add SYS_ADMIN --security-opt apparmor=unconfined 'ghcr.io/borgbase/vorta-docker:local'
9d4463ff3974f1c1429d4e3caafc655298adab7b884c195390937280c4ebbcd4

[Ranbato]

Weird behavior that I can't explain yet. Exec'ing into the container and running borg mount /my/archive /destination/temp works and I can explore the archive just fine. Doing it from the UI says the mount succeeds, but then the mounted directory becomes inaccessible with a permissions denied error.

TL;DR command line works, UI mounts successfully but something makes the mount unavailable

[Ranbato]

Ah, try adding --user app to your docker run command. Looks like root (the default user) doesn't have access to the mount @Sdub76 If that works I'll update the documentation.

[Sdub76]

I confirmed that I can manually mount the archive from the docker exec command line, but I get

docker: Error response from daemon: unable to find user app: no matching entries in passwd file.

if I add --user app to the docker run command. It's odd because you'd think the default root user would be able to access anything. Is it possible to manipulate the UID/GID to 0/0 to run Vorta as root within the docker?

[Sdub76]

It's also worth adding that I only required the

--device='/dev/fuse' --cap-add SYS_ADMIN

options (not privileged mode) for the command-line mount to work properly in my tested environment (Docker version 20.10.5, Slackware Kernel 14.2)

[m3nu]

TL;DR command line works, UI mounts successfully but something makes the mount unavailable

If that's the case, worth checking the command Vorta uses. Is Vorta currently running in the foreground, so we get the logs via the container?

[Ranbato]

This container is specifically set up to follow Docker best practices and not allow Vorta to run as root. Therefore the mount is getting created only for the app user and not for root. Since docker exec defaults to running as root, you don't have access to the mount. The original command I gave was a mistake as it isn't docker run that requires it, it is the exec like so docker exec -it --user app vorta sh

Try that.

[Sdub76]

Yes, I can confirm that this works. Thanks.

Is there any way this could be done in a way that exposes the mount to the underlying OS? Such that I pass in a /mnt/borg folder to the docker container, which mounts the archive and allows the host OS to browse its contents?

I'm comfortable doing all of this from the Borg command line, but my goal in getting this Vorta container working is for less tech-savvy family members. If they could mount an archive to the default location and just browse to it via samba that would be so much easier for them to understand.

The alternative is having them use the "extract" feature instead of "mount" inside Vorta. That gives a reasonably clear GUI for restoring individual files, which is a far more common operation, I suppose.

Either way, I appreciate adding fuse support to the image. I think it makes it a more full-featured package.

[Ranbato]

There is no way I can find to make the mount accessible outside the Docker container. I suspect that is by design.

I have identified some possible ways I can add XTerm or something to the UI to facilitate container access. That will require some changes to the container and it may make sense to move it to a different base container. I'm going to declare it outside the scope of this issue since the desired functionality is available.

If there is nothing else, I'll merge this so it is available and create a separate ticket for the enhancement.

[Sdub76]

I would agree that xterm doesn’t make sense. It’s easy enough to docker exec into a container and many docker front ends provide this by default (docker desktop, Unraid, etc.)

On Wed, Mar 23, 2022 at 2:25 PM Ranbato @.***> wrote:

There is no way I can find to make the mount accessible outside the Docker container. I suspect that is by design.

I have identified some possible ways I can add XTerm or something to the UI to facilitate container access. That will require some changes to the container and it may make sense to move it to a different base container. I'm going to declare it outside the scope of this issue since the desired functionality is available.

If there is nothing else, I'll merge this so it is available and create a separate ticket for the enhancement.

— Reply to this email directly, view it on GitHub https://github.com/borgbase/vorta-docker/pull/7#issuecomment-1076674547, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACVXUFYDVLY3NRTYPJWZ4MLVBNOX3ANCNFSM5RJEUSSQ . You are receiving this because you were mentioned.Message ID: @.***>