Unable to access files through WebDav

[isasmendiagus]

Describe the bug

Although I can access to the web interface, cannot access files through WebDav.
Tested with Nautilus on Ubuntu 22.04 and cadaver CLI

$ cadaver https://10.44.66.22:9200
WARNING: Untrusted server certificate presented for `127.0.0.1':
Certificate was issued to hostname `127.0.0.1' rather than `10.44.66.22'
This connection could have been intercepted.
Issued to: Acme Corp
Issued by: Acme Corp
Certificate is valid from Sat, 25 Feb 2023 13:12:52 GMT to Sun, 25 Feb 2024 13:12:52 GMT
Do you wish to accept the certificate? (y/n) y
Could not access / (not WebDAV-enabled?):
405 Method Not Allowed
Connection to `10.44.66.22' closed.

I have also tried to access through Nautilus without success

Steps to reproduce

1. Install cadaver WebDav CLI. On Debian based OS apt install cadaver
2. Connect to Ocis Proxy over my LAN (https://10.44.66.22:9200)
3. I got an error 'not WebDAV-enabled?'

Expected behavior

As an end user I expect to be able to access my files through WebDav.
I would like to mount a directory with davfs2 and work as if the remote files were local.

I can see here this is easily done with classic OwnCloud. Is that possible as well for Ocis?

Setup

ocis.env

OCIS_URL=https://10.44.66.22:9200
OCIS_INSECURE=true
OCIS_CONFIG_DIR=/etc/ocis
OCIS_BASE_DATA_PATH=/var/lib/ocis

[micbar]

@isasmendiagus You do not provide a WebDAV path to the client, so it cannot work.

[micbar]

The webdav paths are available under https://10.44.66.22:9200/dav/spaces/<space-id>

To find them out, you need to either know the spaceID beforehand or do an authenticated (OpenIDConnect) request against https://10.44.66.22:9200/graph/v1.0/me/drives/ . This will return a JSON response with a list of all available spaces (drives). Each space has its own webDAV URL.

[johnstonjs]

This is incredibly helpful, thank you! It would be even better to have the webDAV URLs provided in the OCIS web interface.

[micbar]

This is incredibly helpful, thank you! It would be even better to have the webDAV URLs provided in the OCIS web interface.

Good point! I see you opened #5435 too.

I would like to see this in the Web Client too. @kulmann @tbsbdr

[isasmendiagus]

Hello @micbar , thank you for your help!
I will try your solution and update the thread if it solves the issue.

[isasmendiagus]

Hello @micbar, I hope you're doing well. I'm having some trouble using oidc-gen. I'm not able to obtain the token or add the configuration. Have you been able to connect to ocis using it?

Here's the command I'm running and the error message I'm getting:

oidc-gen \
 --client-id=xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69 \
 --client-secret=UBntmLjC2yYCeHwsyj73Uwo9TAaecAetRwMw0xYcvNL9yRdLSUi0hUAHfvCHFeFh \
 --issuer https://10.44.66.22:9200 \
 --redirect-uri=http://localhost:12345 \
 --scope="openid offline_access profile email" \
 --cp /etc/ssl/certs/ocis.crt \
 ocis-owncloud

Error: Could not get token endpoint from the configuration endpoint. This could be because of a network issue. But it's more likely that your issuer is not correct.

I'm using the client-id of the desktop application.

If you have any insights or suggestions on how to resolve this, please let me know. Thank you for your help.

Best regards,

[micbar]

can you check with curl what https://10.44.66.22:9200/.well-known/openid-configuration returns?

[Princelo]

i have found the webDavUrl from https://localhost:9200/graph/v1.0/me/drives?$top=0&$skip=0, but i still couldn't access it through webdav. it prints unknown error when i access it by webdav client and 401 by web browser

[micbar]

@Princelo What did my proposed curl request return?

[Princelo]

/.well-known/openid-configuration

➜  ~ curl -k https://192.168.10.102:9200/.well-known/openid-configuration
{
  "issuer": "https://192.168.10.102:9200",
  "authorization_endpoint": "https://192.168.10.102:9200/signin/v1/identifier/_/authorize",
  "token_endpoint": "https://192.168.10.102:9200/konnect/v1/token",
  "userinfo_endpoint": "https://192.168.10.102:9200/konnect/v1/userinfo",
  "end_session_endpoint": "https://192.168.10.102:9200/signin/v1/identifier/_/endsession",
  "check_session_iframe": "https://192.168.10.102:9200/konnect/v1/session/check-session.html",
  "jwks_uri": "https://192.168.10.102:9200/konnect/v1/jwks.json",
  "scopes_supported": [
    "openid",
    "offline_access",
    "profile",
    "email",
    "LibgreGraph.UUID",
    "LibreGraph.RawSub"
  ],
  "response_types_supported": [
    "id_token token",
    "id_token",
    "code id_token",
    "code id_token token"
  ],
  "subject_types_supported": [
    "public"
  ],
  "id_token_signing_alg_values_supported": [
    "RS384",
    "RS512",
    "PS256",
    "PS384",
    "PS512",
    "RS256"
  ],
  "userinfo_signing_alg_values_supported": [
    "RS384",
    "RS512",
    "PS256",
    "PS384",
    "PS512",
    "RS256"
  ],
  "request_object_signing_alg_values_supported": [
    "ES256",
    "ES384",
    "ES512",
    "RS256",
    "RS384",
    "RS512",
    "PS256",
    "PS384",
    "PS512",
    "none",
    "EdDSA"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "none"
  ],
  "token_endpoint_auth_signing_alg_values_supported": [
    "RS384",
    "RS512",
    "PS256",
    "PS384",
    "PS512",
    "RS256"
  ],
  "claims_parameter_supported": true,
  "claims_supported": [
    "iss",
    "sub",
    "aud",
    "exp",
    "iat",
    "name",
    "family_name",
    "given_name",
    "email",
    "email_verified"
  ],
  "request_parameter_supported": true,
  "request_uri_parameter_supported": false
}

[micbar]

the issuer in your oidc-gen is also set to https://192.168.10.102:9200 ?

[Ke1i]

A bit late to the party but initially I could access my ocis webdav shares just fine using "davs://domain/remote.php/webdav" in gnome files or the usual "https://domain/remote.php/webdav" elsewhere.
Anyway, something like "https://192.168.10.102:9200/remote.php/webdav" might work for @Princelo and @isasmendiagus - i've just tried it.
Here's my environment file:

OCIS_URL=https://keli.local:9200
PROXY_TLS=true
OCIS_INSECURE=true
OCIS_LOG_LEVEL=error
OCIS_CONFIG_DIR=/etc/ocis
OCIS_BASE_DATA_PATH=/var/lib/ocis
PROXY_HTTP_ADDR=0.0.0.0:9200
PROXY_USER_OIDC_CLAIM=preferred_username
PROXY_USER_CS3_CLAIM=username
PROXY_ENABLE_BASIC_AUTH=true

And here's the result on gnome files:

And using CX file explorer on Android:

[Princelo]

A bit late to the party but initially I could access my ocis webdav shares just fine using "davs://domain/remote.php/webdav" in gnome files or the usual "https://domain/remote.php/webdav" elsewhere. Anyway, something like "https://192.168.10.102:9200/remote.php/webdav" might work for @Princelo and @isasmendiagus - i've just tried it. Here's my environment file:

OCIS_URL=https://keli.local:9200
PROXY_TLS=true
OCIS_INSECURE=true
OCIS_LOG_LEVEL=error
OCIS_CONFIG_DIR=/etc/ocis
OCIS_BASE_DATA_PATH=/var/lib/ocis
PROXY_HTTP_ADDR=0.0.0.0:9200
PROXY_USER_OIDC_CLAIM=preferred_username
PROXY_USER_CS3_CLAIM=username
PROXY_ENABLE_BASIC_AUTH=true

And here's the result on gnome files:

And using CX file explorer on Android:

i guess u have got something wrong. the path "remote.php" belongs to ownCloud php version, not the OCIS which is developed in golang

[kulmann]

i guess u have got something wrong. the path "remote.php" belongs to ownCloud php version, not the OCIS which is developed in golang

the proxy service in oCIS is clever enough to accept the webdav URLs with or without remote.php. but of course the ones without remote.php are preferred since - as you stated correctly - those originate from and belong to the ownCloud php backend.

[Princelo]

@Ke1i @kulmann @micbar finally i can access both "remote.php/webdav" and "dav/spaces/{space-id}". the environment file provided by @Ke1i saves my days. thx!

[Ke1i]

I'm happy you got it working :)

[gewinh]

Finally got webdav working as well thanks to the .env entries supplied by Ke1i. I have to say I am testing ocis after running php owncloud for many years, I thought it might be time to move to ocis seeing we are at v4. So far I have spent 2 days try to get the nginx proxy stuff working and one day getting webdav working. It is just so hard finding the correct options for what I consider a pretty simple environment. OCIS running on ubuntu 22.04, no docker, NGINX running on a separate server that already has certificates from letsencrypt for *.example.no-ip.org. Challenges still remaining are onlyoffice integration hopefully without getting into the bowels of ocis and what do I do about external storage. Frustrating but appreciative of the developmentss and direction forward.

[Ke1i]

Finally got webdav working as well thanks to the .env entries supplied by Ke1i. I have to say I am testing ocis after running php owncloud for many years, I thought it might be time to move to ocis seeing we are at v4. So far I have spent 2 days try to get the nginx proxy stuff working and one day getting webdav working. It is just so hard finding the correct options for what I consider a pretty simple environment. OCIS running on ubuntu 22.04, no docker, NGINX running on a separate server that already has certificates from letsencrypt for *.example.no-ip.org. Challenges still remaining are onlyoffice integration hopefully without getting into the bowels of ocis and what do I do about external storage. Frustrating but appreciative of the developmentss and direction forward.

Two days huh? That's painful!
Yesterday I took less than ten (10) minutes to get everything up and running while testing the new v4.0.1 on an old debian server, but then again I use caddy as my reverse proxy. Glad the example environment file was of help to you :)

[Ke1i]

While testing v4.0.1 binary on baremetal, I found something interesting:

1. Using the WebDAV mounts feature on DAVx5 app (Android 11), the address https://ocis.ke1i.duckdns.org/webdav/ would mount the root path of my OCIS account.
2. Using the same address, it wouldn't mount in gnome files or Cx file explorer on Android.
3. Using the address ocis.ke1i.duckdns.org/dav/files/ in Cx file explorer would mount the root path of my OCIS account
4. Using the address davs://ocis.ke1i.duckdns.org/webdav/ to mount my OCIS account in gnome files would return a "Not a WebDAV enable share" error but if I added the directory I wanted to access like "Documents" for example so that the new address looks like davs://ocis.ke1i.duckdns.org/webdav/Documents then it would work.

Below is the environment file I'm using.

OCIS_URL=https://ocis.ke1i.duckdns.org
PROXY_TLS=false
OCIS_INSECURE=false
OCIS_LOG_LEVEL=error
OCIS_CONFIG_DIR=/etc/ocis
OCIS_BASE_DATA_PATH=/var/lib/ocis
PROXY_HTTP_ADDR=0.0.0.0:9200
PROXY_USER_OIDC_CLAIM=preferred_username
PROXY_USER_CS3_CLAIM=username
PROXY_ENABLE_BASIC_AUTH=true

[gewinh]

My env file is the same as yours except I have to set PROXY_TLS=true for everything to work with nginx.
Also found some strange behaviour with webdav shares.

1. although it is not supposed to work because we aren't using php davs://my_url/remote.php/webdav in nautilus on ubuntu gives me root access the the file system I can logon as different users and get to that users files. The same davs://my_url/remote.php/webdav path does not work in cx explorer in android.
2. davs://my_url/webdav does not work in nautilus with error not a webdav enabled share
3. davs://my_url/webdav works in cx explorrer on android.

[Ke1i]

My env file is the same as yours except I have to set PROXY_TLS=true for everything to work with nginx. Also found some strange behaviour with webdav shares.

1. although it is not supposed to work because we aren't using php davs://my_url/remote.php/webdav in nautilus on ubuntu gives me root access the the file system I can logon as different users and get to that users files. The same davs://my_url/remote.php/webdav path does not work in cx explorer in android.

I've just tried it again to be sure, for me the address ocis.ke1i.duckdns.org/remote.php/webdav does work in Cx file explorer with v4.0.1 that I'm running on baremetal.
I expect it to work for you as well.

[gewinh]

You are right I tried it again in cx explorer on android and davs://my_url/remote.php/webdav does connect OK. I wonder if the webdav service on ocis has a bit of history from php owncloud.

[Ke1i]

Yeah I think they kept it working in OCIS for backward compatibility.

[micbar]

I am currently working on webDAV docs.

Please see https://github.com/owncloud/ocis/pull/7210/files#diff-bb841f0d006087100279ceb449ad44a90e602201e0bd2a477a137256510bee3cR24-R45

[gewinh]

Now I am confused. Does the statement
" * these dav endpoints are implemented for legacy reasons and should not be used. They are neither performant nor well tested. These legacy endpoints do not take the resourceID as an argument.: "
mean that the /remote.php/webdav syntax will not be supported in the longer term. At this stage I am not using spaces so all the space_id stuff I assume does matter. I just want to access personal shares for users to migrate them with rclone from the owncloud php environment to the OCIS environment. If davs://url/remote.php/webdav isn't the correct url what is the correct one to access personal shares. Thanks.
I honestly thought OCIS was supposed to be easier to implement. At this stage it certainly hasn't been for me, if you want to do anything more complex than simple sharing files.

[micbar]

mean that the /remote.php/webdav syntax will not be supported in the longer term.?

These endpoints are perfectly suited for your purpose. Currently they are part of the product. If we remove them in the future, they will get a deprecation notice. So currently nothing to worry about it.

Different Semantics

oCIS uses spaces for everything. Even the "personal" area in ocis is a space. It can be also accessed via /dav/spaces/{spaceID}

The remote.php/webdav endpoint tries to mimic the old oc10 behavior. It shows all received shares inside the personal space under the Shares subfolder. This subfolder is not writable. So you cannot upload data via rclone into the Shares folder inside remote.php/webdav

In oCIS, all received shares are deliberately moved outside of the "Personal Space". They can be accessed via the legacy endpoint remote.php/webdav/Shares or via a static virtual Shares Jail with a fixed spaceID. /dav/spaces/a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668

The personal space without the mounted Shares is acessible under /dav/spaces/{your-personal-space-id}. Your personal space id can be retrieved from the "Listing All my Spaces" API call. https://owncloud.dev/libre-graph-api/#/me.drives/ListMyDrives

[micbar]

I honestly thought OCIS was supposed to be easier to implement. At this stage it certainly hasn't been for me, if you want to do anything more complex than simple sharing files.

That is sad to hear. What is your usecase?

[micbar]

Challenges still remaining are onlyoffice integration hopefully without getting into the bowels of ocis and what do I do about external storage. Frustrating but appreciative of the developmentss and direction forward.

Please check out our deployment examples in the ocis repo. We are trying to keep them very simple. The largest one is ocis_wopi with OnlyOffice and Collabora and Full Text Search.

NOTE: oCIS itself is only a part of the solution. To get that Full Feature Set, you need to run a service mesh (LDAP, tika, traefik, wopiserver, onlyoffice, an OpenIDConnect provider and more).
Running, maintaining and orchestrating of many services is always hard to do on bare metal without containers. We always recommend to use containers and orchestrate via docker, docker compose, podman or kubernetes.

[gewinh]

Thanks for the information. My usecase is that I am running a private family cloud about 8 users and 4T of cloud storage plus some external mounts. I have been using owncloud for about 10 years and migrate the setup about every couple of years. The current setup is a raspberry pi4 running ubuntu server 22.04 and owncloud 10.7 with the datastore on a NAS. Everything is behind a NGINX reverse proxy that supports a number of other services. I stayed with owncloud when nextcloud forked off because owncloud worked for me. It is now time for me to look at the next iteration of my cloud service, that is why I am playing with OCIS. The impression I have so far indicates that owncloud's future strategy is more towards the enterprise and not towards small users, like myself.
Info like
"To get that Full Feature Set, you need to run a service mesh (LDAP, tika, traefik, wopiserver, onlyoffice, an OpenIDConnect provider and more)
Running, maintaining and orchestrating of many services is always hard to do on bare metal without containers. We always recommend to use containers and orchestrate via docker, docker compose, podman or kubernetes."

is way beyond what I need to get involved in or my time and skill base can handle.

I think my next test with be to do a snap install of Nextcloud and follow the instructions to integration onlyoffice (https://ubuntu.com/tutorials/how-to-integrate-onlyoffice-with-nextcloud-on-ubuntu#1-overview). Everything else about nextcloud eg webdav federation, backup etc. etc looks pretty similar to what I am doing now but with a support strategy for the future unlike owncloud 10.
I am sure OCIS will be a great product for larger cloud environments, so keep up to good work.

[Ke1i]

The impression I have so far indicates that owncloud's future strategy is more towards the enterprise and not towards small users, like myself. Info like "To get that Full Feature Set, you need to run a service mesh (LDAP, tika, traefik, wopiserver, onlyoffice, an OpenIDConnect provider and more) Running, maintaining and orchestrating of many services is always hard to do on bare metal without containers. We always recommend to use containers and orchestrate via docker, docker compose, podman or kubernetes."
is way beyond what I need to get involved in or my time and skill base can handle.

Like @gewinh, I use OCIS as a private family cloud with less than three (3) users. I don't need something like LDAP or an OpenIDConnect provider for my usecase. The OCIS binary just works for what I need and it shouldn't be overly complicated to get OCIS up and running for simple self-hosters like myself.
So, the OCIS web interface logs you in and presents your 'Personal Space' after supplying an appropriate username and password and I think it should be that simple with webdav via a universal URL. The web URL doesn't expect a random string of alphanumericals in the name of 'spaceID' to present your 'Personal Space'. If the remote.php/webdav endpoint was shoehorned into OCIS to mimic the old owncloud, a universal endpoint like ocis.url/webdav shouldn't be impossible to implement. Is there a reason for pushing the spaceID thing for simple webdav access? Because lets be honest, ocis.url/webdav is much easier to work with than ocis.url/dav/spaces/{your-personal-space-id}

[micbar]

I am sure OCIS will be a great product for larger cloud environments, so keep up to good work.

I don't think so, honestly. Please do not compare two different things.

NC and oc10

Both solutions are based on the LAMP (Linux, Apache, MySQL, PHP) stack. The LAMP stack itself is huge and you can configure thousands of config values and find many ways to shoot yourself in the process.

NC and oc10 need a lot more resources (CPU, memory) than ocis and are slower in performance.

oCIS

oCIS needs no LAMP stack and no database. That is IMO a big relief and really sensational.

It brings its on webserver, its own LDAP and a small OpenIDConnect provider in one binary.

The setup is quite simple, provide a handful of ENV variables and you are ready to go. So this is very easy and handy for small deployments.

Challenges in both worlds

Reverse proxy and SSL has always been a challenge and will always be.

If you want to setup OnlyOffice with both of them, you will have a lot of struggle. E.g OnlyOffice needs PostgreSQL, RabbitMQ, Redis as a dependency. The "simple way" to setup onlyoffice is to use the all in one docker image.

To setup full text search in oC10 or NC, you need an ElasticSearch Server or Cluster. You surely want to avoid to install and maintain that beast.

oCIS has a built-in search backend based on bleve search. If you just add apache tika for content indexing, you will get Full Text search with very low effort.

Examples

We are really trying to make things very accessible. Use the ocis_wopi example. docker-compose up and you are ready to go.

is way beyond what I need to get involved in or my time and skill base can handle

I have been product owner of oc10 for some years, now for oCIS and i know Nextcloud. There seems to be a strong opinion in the oc10 or NC world that bare metal installations are "easier".

As I have been part of both worlds intensively, I can just say, it is the opposite. Bare metal installations have just so many issues with networking, ports, Hostnames, configuration and package management. The only thing which is admittedly a little bit more complicated with containers is persistance. But you will very quickly understand the concept of persistent volumes.

I hope you can value my opinion.

[micbar]

Because lets be honest, ocis.url/webdav is much easier to work with than ocis.url/dav/spaces/{your-personal-space-id}

It is missing in the docs example. ocis.url/webdav/ works (needs a trailing slash). It is the same handler, just routing.

[micbar]

Is there a reason for pushing the spaceID thing for simple webdav access?

Yes, very simple: Lookups by ID are much faster.

[Ke1i]

I have been product owner of oc10 for some years, now for oCIS and i know Nextcloud. There seems to be a strong opinion in the oc10 or NC world that bare metal installations are "easier".

Baremetal NC was never easy unless done via Snap route. Apache, php, redis, using a 'proper' database, imagemagick, optimizations, hardening etc. What I love about OCIS is the fact that I can get things running in less than ten (10) minutes with just a single binary. All I need to do is to create the ocis user, create some directories and copy over sample environment and systemd unit files. And I can't stress enough about this one other thing, OCIS is way faster :)
I like OCIS mostly because of this, speed and ease of deployment.

It is missing in the docs example. ocis.url/webdav/ works (needs a trailing slash). It is the same handler, just routing.

Good to know, it should be documented so folks wouldn't need to keep guessing if it's officially supported or not. it's a lot cleaner and easier to remember IMHO. I hope it'll be supported in the long run going forward.

Yes, very simple: Lookups by ID are much faster.

Maybe for machines, I'm just a simple self-hoster. But what do I know ¯_(ツ)_/¯
Anyway thanks for your input, much appreciated.

[gewinh]

Great discussion. Thanks for all the input, not sure this is the right place for this type of discussion but it seems to be working.
I haven't given up yet because I am the new kid on the block and am still trying to come to grips with OCIS.
Given my small setup speed has never been my problem, reliability, keeping things simple and not loosing files is a high priority.

Getting back to webdav.

As a test I have used rclone/webdav to copy shares from owncloud 10 to OCIS (15000 folders and files) this went OK and the data appeared in the Personal area of the appropriate user. So I don't understand the above info.
"The remote.php/webdav endpoint tries to mimic the old oc10 behavior. It shows all received shares inside the personal space under the Shares subfolder. This subfolder is not writable. So you cannot upload data via rclone into the Shares folder inside remote.php/webdav" If the personal space is in the shared folder according to this statement I shouldn't be able to write to it.

Next problem is when I examine the data area on the disk I think the data is in my_datadisk_mount_point/storage/users/spaces

With owncloud10 I have a nightly backup job that backs up the database and the data area I have a restore script that I have used to rebuild owncloud10 and the database and data, so I feel comfortable about not having a disaster.

As per the docs if you run the init command on an existing setup, the data get screwed, certainly true from my experience.

As files aren't stored as normal filenames is there a recommended backup process for OCIS or would rclone be the best?

[micbar]

If the personal space is in the shared folder according to this statement I shouldn't be able to write to it.

The other way around. The shares folder is inside the personal space.

[micbar]

As per the docs if you run the init command on an existing setup, the data get screwed, certainly true from my experience.

Yes. Only run it once to secure your installation.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[micbar]

Update. In ocis 5.0.0 you have the WebDAV Url in the web UI.

Enable the feature

Open File Details

[micbar]

Additional Info

Cyper Duck and Mountain Duck are now supporting OIDC.

Example has been added to our deployment examples.

• Add example config for 3rd party WebDAV client Cyberduck (and Mountain Duck) #7649