Problem with NextCloud-Client App-VM (unable to login on 2nd boot)

[one7two99]

Hello,

I want to use a dedicated AppVM to sync data to a private NextCloud-Server.

I have setup a dedicated template for this, which is based on
fedore-30-minimal (as all my other templates).

Configuration of the template and the AppVM was straight forward and I
was able to make an initial sync.

But after I have restarted my NextCloud-Client AppVM I'm asked for
credentials again and even if login again, the sync doesn't start.

I've also tried to use a NextCloud AppToken for my user, but this had
the same effect.

Can someone explain why I the login/sync fails after rebooting the AppVM?

This are the steps to build a NextCloud-Client-Template and an AppVM
based on this template.

All steps have to be run from dom0:


---- start ----

Template=fedora-30-minimal
TemplateName=t-fedora-30-storage

# Remove an existing template
if [ -d /var/lib/qubes/vm-templates/$TemplateName ];
   then qvm-kill $TemplateName;
   qvm-remove --force $TemplateName;
fi

qvm-clone $Template $TemplateName

qvm-run --auto --pass-io --no-gui --user root $TemplateName \
  'dnf -y update'

# mandatory: install Nextcloud + Qubes Basics
qvm-run --auto --pass-io --no-gui --user root $TemplateName \
  'dnf -y install nextcloud-client nautilus qubes-core-agent-nautilus \
   qubes-usb-proxy mlocate qubes-core-agent-networking'

# optional: Some more usefull tools
qvm-run --auto --pass-io --no-gui --user root $TemplateName \
  'dnf -y install nano mc less unzip'

# optional: Nice(r) (Gnome-)Terminal
qvm-run --auto --pass-io --no-gui --user root $TemplateName \
  'dnf -y install gnome-terminal qubes-usb-proxy terminus-fonts \
   dejavu-sans-fonts dejavu-sans-mono-fonts'

qvm-shutdown $TemplateName

qvm-create --template=$TemplateName --label=blue my-nextcloud

# add Nextcloud-Sync-Client to Qubes Menu
# Login/Configure Nextcloud-Client (you need to login via Browser, this
can be done in another AppVM)
# Hint: Add an App-Password/Token

----- end ----


Thanks for your help.

[799]

[*Null* **]

Sorry my initial reply was the wrong answer.

To set up a login that is persistant you need to do it in the template with the occ commands. Any user made in the appvm will not survive a reboot.

The nextcloud storage area needs to be made persistant using the qubes-bind-dirs directory in the appvm, the qubes docs cover that.

I am able to stay logged in with the nextcloud app and sync via webdav between reboots in this manner.

Are you also trying to sync other appvms?

[799]

Hello,

*Null* ** <s.w.i.m....@gmail.com> schrieb am Do., 15. Aug. 2019, 14:46:

Sorry my initial reply was the wrong answer.

To set up a login that is persistant you need to do it in the template with the occ commands. Any user made in the appvm will not survive a reboot.

What exactly is meant by "occ commands"?

The nextcloud storage area needs to be made persistant using the qubes-bind-dirs directory in the appvm, the qubes docs cover that.

I am able to stay logged in with the nextcloud app and sync via webdav between reboots in this manner.

Thank you for the feedback, I don't understand why I need to make changes regarding the storage area.

As far as I know the Nextcloud data is stored in /home/user which should survive the a reboot as long as it is a normal AppVM.

Are you also trying to sync other appvms?

No I have just build a template (as describes) and build an AppVM from this template.

[799]

[*Null* **]

OCC commands:

https://docs.nextcloud.com/server/16/admin_manual/configuration_server/occ_command.html#user-commands-label

In qubes you have to specify the file path to occ(in the docs it lets you call occ by itself).
So for a typical fedora/apache/nc install in the template you would enter:

Sudo -u httpd(or apache) php /usr/share/nextcloud/occ [enter commands]

OCC is your main way of administering nextcloud in qubes so that link will help.

Qubes appvms do not keep anything outside of /rw so you would need to migrate the storage folder into /rw (https://help.nextcloud.com/t/howto-change-move-data-directory-after-installation/17170)

Or you can declare certian folders or files to be persistent. https://www.qubes-os.org/doc/bind-dirs/

This is done in the appvm. Dont designate all of nextcloud to be persistent or if someone hacks the nextcloud appvm its there forever. It is bad enough you are doing it to the file folder.

I assume you installed nextcloud in the template and set up an admin account in the process. So when you fire up the appvm anything you do in there will be erased until you add your users via occ in the template and preserve the file folder.

Once you do all that it will work fine from your home network, exposing it to the world is a bit of a pain and introduces an attack vector obviously.

[*Null* **]

Oh yeah /home is saved too... I thought just /rw. It is advised on the nextcloud hardening guide to not keep it in the default location and on my setup I had to move it anyways because of how the machine is set up.

[799]

Hello,

*Null* ** <s.w.i.m....@gmail.com> schrieb am Do., 15. Aug. 2019, 19:12:

OCC commands:

https://docs.nextcloud.com/server/16/admin_manual/configuration_server/occ_command.html#user-commands-label (...)

Now I understand what you've meant, regarding the movement of directories. This was related to running a Nextcloud Server within Qubes OS.

In my case I am connected from an AppVM (Qubes OS) to an external Nextcloud-Server (not running Qubes OS).

As all Client-settings _should_ be safe in an AppVM I don't understand why I need to login after the first boot of the AppVM and why even after login in, the synchronization is not working again.

[799]

[*Null* **]

oh I am dumb, perhaps try logging in with your template vm, do the key exchange, and then shut it down. It may stick into the appvm?

On Thursday, August 15, 2019 at 11:15:46 AM UTC-7, 799 wrote:

Hello,

[Stefan Leibfarth]

Hello,

Am 15.08.2019 um 00:03 schrieb one7two99:
> I want to use a dedicated AppVM to sync data to a private NextCloud-Server.

[...]

> Can someone explain why I the login/sync fails after rebooting the AppVM?
>
> This are the steps to build a NextCloud-Client-Template and an AppVM
> based on this template.
>
> All steps have to be run from dom0:
>
>
> ---- start ----
>
> Template=fedora-30-minimal
> TemplateName=t-fedora-30-storage

[...]

> can be done in another AppVM)
> # Hint: Add an App-Password/Token
>
> ----- end ----

Seems fine to me.

I'd guess it's not directly Qubes related, maybe this problem:
https://help.nextcloud.com/t/nextcloud-client-asks-for-password-every-time-it-starts/28591/3

Try to start the client from the command line and see if there are any
errors.

If that doesn't help try to install the client in an AppVM based on the
default Fedora-Template. If that's running fine you might miss some
required packages (see link above).

[799]

Hello,

On Fri, 16 Aug 2019 at 11:22, Stefan Leibfarth <ste...@leibfarth.org> wrote:

[...]

I'd guess it's not directly Qubes related, maybe this problem:
https://help.nextcloud.com/t/nextcloud-client-asks-for-password-every-time-it-starts/28591/3

I tried nearly everything from this forum post, I also tried to use other templates fedora-29, fedora-30, still the same problem.

I also tried to install gnome-keyring but it doesn't make a difference.

Anyelse has a Nextcloud CLIENT (not server) running in Qubes and give me a hint, why I need to re-enter my credentials after boot and even after the nextcloud client is not pocking up the sync again.

[799]

[sourcexorapprentice]

libgnome-keyring, not just gnome-keyring.

Various forums suggest an issue (is there though?) in Fedora where PAM and the gnome keyring do not play nice together and an additional theory that the Fedora keyring is just not making Nextcloud entries due to some bug.

My current solution:

1. Boot your template Fedora VM and then install the gnome keyring:

dnf install -y libgnome-keyring

sudo shutdown -h now

2. Restart your qubes AppVM and login to your Nextcloud client with your password, restart

3. Nextcloud starts and is good to go without password

If 3 fails (did for me), then you may want to blast your keyrings (warning: you're deleting your keyrings, so other saved password...), so in the AppVM just run "sudo dnf -y remove gnome-keyring && sudo dnf -y install gnome-keyring" reboot and enter a null password on boot, then repeat step 2.

I'm still anxious about this because my keyring uses as...NULL password! My understanding is that this is an acceptable risk and has the same logic as the null root password. Someone who is local on the AppVM is going to be able to escalate to root anyway, and therefore will own the keyring so you're pwned anyway so just make the keyring null so it's less annoying. Is this horribly wrong?

Example of suggested solutions:

https://github.com/nextcloud/desktop/issues/427

[sourcexorapprentice]

*long day, missed the part where I blasted my old keyrings if step 3 fails:

sudo rm -rf /home/user/.local/share/keyrings

I had no saved passwords/keys but it was still an issue somehow, so this forced the new first-time keyring password prompt on AppVM reboot that I left blank. So apparently libgnome-keyring is a dependency. No idea what the Nextcloud forum are referenced with libgnome-keyring0.