Error on Setting up client

[Emmanuel Mdoma]

Hello Team,

I am trying to set up Minarca on a cloud vps and while all is done on the server side, I keep getting an error on the client side when installing. 

'Process returned a non-zero exit status (1)'

Please advise

Regards,

Emmanuel

[Patrik Dufresne]

Hello Emmanuel,

The problem is most likely on the server side. I took note to improve the error message for this scenario in the next release and provide better guidance about how to solve the issue.

Take a look at /var/log/minarca/shell.log. Minarca may have issues creating the user namespace.

--
You received this message because you are subscribed to the Google Groups "Minarca Data Backup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to minarca+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/minarca/CAJEaRd6n15KvO-MRXc4Vt%2B2TvM4ScSt6qHioqXJ9VyYkeU9PZQ%40mail.gmail.com.

--

IKUS Software

https://www.ikus-soft.com/

514-971-6442

St-Colomban, QC J5K 1T9

[Emmanuel Mdoma]

Hi 

Thank you for your response. I hope this message finds you well.

As detailed in the attached log file, there appears to be a recurring problem related to User Namespace Hardening, which I initially suspected to be specific to Debian systems.

Despite this being an Ubuntu 24.04.2 LTS VPS installation, the error persists, suggesting a deeper configuration or permission-related issue. The log entries repeatedly indicate failures in creating the rdiff-backup jail, with specific PermissionError related to /proc/self/setgroups.

Given the nature of this problem, I would greatly appreciate your guidance on how to adjust the system to allow client connections.

Thanks :)

Regards,

Emmanuel

To view this discussion visit https://groups.google.com/d/msgid/minarca/CAM%3D_CK7DmM7PTo1TeaLmj0_EqoQQs4cjUGUbecbyOQu2eR7_LA%40mail.gmail.com.

[Patrik Dufresne]

Hello Emmanuel,

As you highlight, the problem is related to the creation of unprivileged user namespace creation. Your system doesn't allow its creation which is blocked and raises a permissions error.

Usually, if you install minarca-server on Debian or Ubuntu in a VM, it should work out of the box. But if you install it in a container, it won't work and you need to enable the feature on the guest host.

You should check if unprivileged user namespaces are enabled:

cat /proc/sys/kernel/unprivileged_userns_clone

You can check if it's working with  "unshare --user --net bash" as a non-root user.

To view this discussion visit https://groups.google.com/d/msgid/minarca/CAJEaRd7Q%3Dwoq2RSsMEqVxBoTTxphpsNqfwCmTUjaLZgK%2BMnprw%40mail.gmail.com.

[Brian Errett]

I think I am having the same problem - this is not a docker install it is a package install on a VM of ubuntu 24.04.02  - as per your suggestions I tried 

cat /proc/sys/kernel/unprivileged_userns_clone  and the result is "1"

and  "unshare --user --net bash" as a non-root user returns to prompt with no output.

the last bit in the shell.log on the server shows the following...

PermissionError: [Errno 13] Permission denied: '/proc/self/setgroups'
[2025-03-11 14:15:29,906][INFO   ][10.0.2.110][minarca][PID:3461][minarca_server.shell] running command [/usr/bin/rdiff-backup-2.2 --server] in jail [/nfs/purcell/mina
rca/backups] for: minarca/6.0.3 rdiff-backup/2.2.6 (Linux 6.8.0-55-generic x86_64)
[2025-03-11 14:15:29,941][ERROR  ][10.0.2.110][minarca][PID:3461][minarca_server.shell] Fail to create rdiff-backup jail. If you are running minarca-shell in Docker, m
ake sure you started the container with `--privileged`. If you are on Debian, make sure to disable userns hardening `echo 1 > /proc/sys/kernel/unprivileged_userns_clon
e`.
Traceback (most recent call last):
 File "/opt/minarca-server/lib/python3.12/site-packages/minarca_server/shell.py", line 68, in _jail
   process = subprocess.Popen(
             ^^^^^^^^^^
 File "/opt/minarca-server/lib/python3.12/site-packages/snakeoil/contexts.py", line 239, in __invoke_trace_funcs
   func(frame, event, arg)
 File "/opt/minarca-server/lib/python3.12/site-packages/snakeoil/contexts.py", line 214, in __exit_context
   raise self.ParentException()
snakeoil.contexts.SplitExec.ParentException

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
 File "/opt/minarca-server/lib/python3.12/site-packages/minarca_server/shell.py", line 192, in main
   _jail(userroot, cmd)
 File "/opt/minarca-server/lib/python3.12/site-packages/minarca_server/shell.py", line 67, in _jail
   with Jail(userroot):
 File "/opt/minarca-server/lib/python3.12/site-packages/snakeoil/contexts.py", line 165, in __exit__
   raise exc
PermissionError: [Errno 13] Permission denied: '/proc/self/setgroups'

Any help appreciated...

-Brian

[Patrik Dufresne]

Hello Brian,

Then I'm not sure what's wrong.

The error PermissionError: [Errno 13] Permission denied: '/proc/self/setgroups' usually occurs when unprivileged user namespaces are not allowed. Since you’ve already checked and enabled unprivileged_userns_clone, the issue might be related to additional security restrictions in place on your system.

Is it possible AppArmor or SELinux is enforcing restrictions ?

To view this discussion visit https://groups.google.com/d/msgid/minarca/eca295b4-dad7-49d7-9d6d-b764706ffd48n%40googlegroups.com.

--

** Par mesure d'efficacité, je consulte mes courriels une fois par jour.

[Brian Errett]

Since this is ubuntu 24 it would be an apparmor issue, but I have tried completely turning off apparmor and get the same results.

Thanks,

-Brian

[Patrik Dufresne]

Hello Brian,

Could you try with Debian Bookworm ? Just to verify if it's a ubuntu vs debian or if the problem is specific to your setup...

To view this discussion visit https://groups.google.com/d/msgid/minarca/e75b90d8-e0a0-4131-b018-2a3cccd3f890n%40googlegroups.com.

[Clive Allen]

Hi,

I also had the same issue with a fresh Ubuntu 24.04 install on bare metal. The client failed to connect, but for every attempt I received an email that a new SSH key had been created. I did attempt to disable userns hardening but without success. A fresh Debian Bookworm install on the same hardware worked.

[Patrik Dufresne]

Hello Clive,

There might be an issue or something else blocking the user namespace creation on Ubuntu 24.04. Could any of you create an issue in Gitlab with as many details as possible ?

- The OS version, architecture, the exception raised, etc.

I will try to find time to reproduce the issue.

Thanks

To view this discussion visit https://groups.google.com/d/msgid/minarca/1d7c93f6-7eed-4eb5-9499-7022f3ecb76an%40googlegroups.com.

[Patrik Dufresne]

I’ve spent some time investigating the issue regarding the behavior differences between Ubuntu 24.04 and Debian Bookworm.

The discrepancy is related to a specific Ubuntu feature, which you can read more about here: Ubuntu 23.10 - Restricted Unprivileged User Namespaces.

The ideal solution would be to provide an AppArmor profile for Minarca-shell. Unfortunately, I was unable to create one within a reasonable timeframe. If anyone is willing to take on this task, your help would be greatly appreciated.

In the meantime, it’s possible to temporarily disable the enforcement by running the following command:

echo 0 > /proc/sys/kernel/apparmor_restrict_unprivileged_userns

--

ATTENTION : Je serai en vacances du 2 au 21 mai 2025.
ATTENTION: I will be on vacation from May 2 to May 21, 2025.

[Patrik Dufresne]

Could any of you confirm if this is fixing the issue on your side ?

[FVDBS]

Oh yeah, working a lot better. No reinstall needed, just ran the command and restarted the client. Entered a name for the backup, my login and pwd and the url for the server and less than a sec later I see the file selection window which previously I did not get.

The echo 0 > /proc/sys/kernel/apparmor_restrict_unprivileged_userns command solved the issue for me.

Now let's see if I can take a first backup :-)

[Patrik Dufresne]

Thanks, FVDBS, for your feedback.

You may also want to persist this change across reboots by creating a file at /etc/sysctl.d/99-example.conf with the following content:

kernel.apparmor_restrict_unprivileged_userns = 0

To view this discussion visit https://groups.google.com/d/msgid/minarca/90e1314c-6428-4116-aa19-4efde90b288cn%40googlegroups.com.

[FVDBS]

No problem.

So.... the backup ran and finished without issues. This morning checking the situation and your feedback, I shutdown the client, booted it back up, ran the minarca client and as expected, I got the same error.

I created the persistent solution /etc/sysctl.d/99-minarca.conf, entered the data as mentioned above, rebooted the client again and I am back to the same error:

 process returned a non-zero exit status (1)

I next deleted the 99-minarca.conf file, rebooted, ran the echo 0 > /proc/sys/kernel/apparmor_restrict_unprivileged_userns manually, but I still get the error

Looking at the content of apparmor_restrict_unprivileged_userns it is simply the 0 as expected.

Let me do some more testing and get back to you.

[Patrik Dufresne]

Hello FVDBS,

If you need further help to solve your issue, you may want to share your client and server logs (/var/log/minarca) here.

To view this discussion visit https://groups.google.com/d/msgid/minarca/972f980e-6baf-4f7b-a657-54980d65637cn%40googlegroups.com.

[FVDBS]

Hi everyone,

I have been running backups successfully for the past few days and I no longer get the error.

What solved the issue for me was as mentioned above...

I created the /etc/sysctl.d/99-minarca.conf file with a single line in there: kernel.apparmor_restrict_unprivileged_userns = 0     That is single spaces before and after the = sign

I did multiple reboots (cold) and just plain reboots and it is running stable. Even after keeping both powered down for the night and booting them up in the morning was all good.

Just to clarify, I am doing this on a clean Ubuntu 24.04 (fully patched, bare metal) client and a fully patched, bare metal Ubuntu 24.04 server without GUI. I also ran a sudo apt install rdiff-backup on both as i saw in the log files that this was missing, but as confirmed by Patrik, you can skip this step.

The dashboard is showing a multitude of backups, all without issues and no errors, so the above is a working solution for my specific use case.

Thanks for the help Patrik!

[Patrik Dufresne]

I've released a new patched version of Minarca Server v6.0.6 with this modification. This should make it easier for others trying out Minarca to get it working out of the box on Ubuntu.

@FVDBS if you upgrade to this version, you may want to delete the file 99-minarca.conf as the installation will create it automatically.

Thanks for your feedback.

To view this discussion visit https://groups.google.com/d/msgid/minarca/7108f63b-b028-422c-bfe0-048ddc89be1dn%40googlegroups.com.

[Stefan Templin]

Hi everyone. 

I am still facing this Problem using the docker setup.
Im currently on a fresh installation of Ubuntu 25.04 Plucky.

Per default the apparmor_restrict_unprivileged_userns setting is 1.

I installed a fresh minarca using 6.1.3.dev4-g18ca95f and the docker compose template.
After startup of the container I encounter this problem when connecting with the windows client (6.1.2)

The shell.log gives me this.

Traceback (most recent call last):

  File "minarca_server/shell.py", line 204, in main
  File "minarca_server/shell.py", line 81, in _jail
  File "snakeoil/contexts.py", line 165, in __exit__

PermissionError: [Errno 13] Permission denied: '/proc/self/setgroups'

[2025-06-26 21:50:36,561][INFO   ][10.0.0.30][admin][PID:781][__main__] running command [/usr/bin/rdiff-backup-2.2 --server] in jail [/backups/admin] for: minarca/6.1.2 rdiff-backup/2.2.6 (Windows 10 AMD64)
[2025-06-26 21:50:36,567][ERROR  ][10.0.0.30][admin][PID:781][__main__] fail to create rdiff-backup jail

Traceback (most recent call last):

  File "minarca_server/shell.py", line 82, in _jail
  File "snakeoil/contexts.py", line 239, in __invoke_trace_funcs
  File "snakeoil/contexts.py", line 214, in __exit_context

snakeoil.contexts.SplitExec.ParentException

During handling of the above exception, another exception occurred:

Traceback (most recent call last):

  File "minarca_server/shell.py", line 204, in main
  File "minarca_server/shell.py", line 81, in _jail
  File "snakeoil/contexts.py", line 165, in __exit__

PermissionError: [Errno 13] Permission denied: '/proc/self/setgroups'

After finding this thread I discovered, that it's source is the setting of apparmor on ubuntu.
Is anything planned making the container work out of the box again, without changing the setting on the host? (if even possible)

Kind regards,
Stefan