Werkt KPN Cloud met besturingssysteem Linux?

Dag ​@PjotrV :

KPN Cloud benaderen via WebDAV

WebDAV is een communicatieprotocol dat gebruikt kan worden om bestanden van en naar een server te verplaatsen. Maak je gebruik van een besturingssysteem waarvoor geen KPN Cloud app is (zoals Linux) of wil je liever een eigen app voor bestandsbeheer gebruiken, dan kun je KPN Cloud ook via WebDAV bereiken.

Om via WebDAV met KPN Cloud te verbinden gebruik je de URL: https://share.kpnmail.nl/drive

Inloggen doe je met je e-mailadres en het daarbij behorende wachtwoord. 

...

Hoi ​@PjotrV, welkom op de community. Het stukje wat Dicksooo kopieert komt uit onze Kennisbank: 

Daar wordt ook uitgelegd waar alles wordt opgeslagen, op servers in Nederland 😉

In de KPN Community wordt aangegeven dat KPN Cloud / KPN Drive via WebDAV te benaderen zou zijn, met als URL:
https://share.kpnmail.nl/drive

Ik heb dit recent uitgebreid technisch getest onder Linux (Linux Mint), met davfs2, mount, curl en protocolchecks. Daarbij loop ik tegen tegenstrijdig gedrag aan, waar ik graag officiële opheldering over krijg.

Feiten uit mijn tests:

• De URL https://share.kpnmail.nl/drive is bereikbaar via de browser.
• Mounten via davfs2 resulteert in een FUSE-mount, waarbij deels directorystructuur zichtbaar wordt (o.a. Userstore).
• Tegelijkertijd geeft mount.davfs expliciet: “the server does not support WebDAV”.
• Een directe PROPFIND-test:

resulteert in een 401 met HTML-response, niet in een WebDAV 207 Multi-Status met DAV XML.
• Ook ontbreken DAV-headers (DAV: 1 / DAV: 1,2) bij OPTIONS/HEAD requests.

Dit wijst erop dat:

• de endpoint wel HTTP(S) aanbiedt,

• maar geen volledige WebDAV-implementatie conform RFC 4918.

In de praktijk betekent dit dat:

• directory listing deels werkt,

• maar openen/bewerken van bestanden leidt tot I/O-fouten,

• locking en betrouwbare writes ontbreken,

• en de mount niet bruikbaar is als werkmap onder Linux.

Mijn concrete vraag aan KPN:

1. Ondersteunt KPN Drive technisch gezien volwaardige WebDAV (ja/nee)?

2. Zo ja: wat is dan de officiële WebDAV-endpoint URL en documentatie?

3. Zo nee: kan de community-informatie hierover worden aangepast, zodat Linux-gebruikers geen onjuiste verwachtingen krijgen?

Ik stel deze vraag nadrukkelijk ter verduidelijking, niet als klacht.
Duidelijkheid zou veel tijd en verwarring bij gebruikers schelen.

Alvast dank voor een technisch inhoudelijke reactie.

Ik gebruik zelf rclone. Daarmee heb ik diverse online clouds aangekoppeld. Ook die van KPN. En dat werkt prima.

Dank Marlon voor de suggestie. Ik heb /drive/Userstore ook getest als mogelijke WebDAV-root.
Hoewel daar inderdaad mijn bestanden zichtbaar zijn, blijkt dit geen volwaardige WebDAV-endpoint.

Een PROPFIND-test:

geeft een 401 met HTML-response, geen 207 Multi-Status met DAV XML en zonder DAV: headers.
In de praktijk resulteert dit in gedeeltelijke directory listing, maar met I/O-fouten bij openen/bewerken en zonder locking of betrouwbare writes.

Daarom lijkt /Userstore onderdeel van de webapp-backend, niet een echte WebDAV-implementatie.

Dank voor je reactie. Met rclone kan ik KPN Drive inderdaad ook benaderen (mappen en bestanden zijn zichtbaar, downloaden werkt vaak).
Waar ik tegenaan loop, is dat dit geen volwaardige WebDAV-implementatie lijkt te zijn: mounts en werken-in-place geven I/O-fouten, en PROPFIND/OPTIONS leveren geen DAV-headers of 207-responses.

Gebruik jij rclone vooral voor kopiëren/downloaden, of ook voor mount/sync en bewerken van bestanden? Dat verschil lijkt hier cruciaal.

Rclone is gewoon een systeemservice die 24/7 actief is. Ik kan lokaal bestanden bewerken en opslaan. Die komen dan meteen in KPN cloud te staan.

Helder, thanks! Dus jij draait rclone als systemd-service (rclone mount) zodat de KPN Cloud als “schijf” blijft hangen en wijzigingen direct syncen. Welke backend/URL gebruik jij precies voor KPN (WebDAV endpoint), en gebruik je nog specifieke flags (bijv. --vfs-cache-mode, --dir-cache-time, --poll-interval) om bewerken in-place stabiel te houden? (Ik krijg met curl op de WebDAV URL nog een 401, dus ik zoek de juiste endpoint + rclone instellingen.)

rclone.conf bevat:

Het draait op Arch onder gebruikersnaam "rclone".

https://archlinux.org/

[root@beheer ~]# pacman -S rclone
[root@beheer ~]# useradd -m rclone
[root@beheer ~]# passwd rclone

[root@beheer ~]# pacman -S fuse3
[root@beheer ~]# loginctl enable-linger rclone
[root@beheer ~]# nano /etc/fuse.conf
---------------------------
user_allow_other
---------------------------

Goed om te lezen dat het met de hulp van Marlon is gelukt ​@PjotrV! Ik zal het gemarkeerde antwoord ook even aanpassen naar jouw laatste antwoord. Als anderen hetzelfde proberen kunnen zij het daarmee ook makkelijker gebruiken 🙂

Ik probeer hier ook share.kpnmail.nl via davfs2 te gebruiken in Fedora43 en Debian13, maar het is onbruikbaar. Het lijkt wel te werken met een lokale Apache webdav server. Tegelijk gaan er ook berichten rond dat de kernel implementatie van davfs niet meer goed werkt, dus ik weet niet aan welke kant ik het moet zoeken.   

Het vreemde is, dat het gvfs systeem wel lijkt te werken, dus mounten van share.kpnmail.nl via GUI, de MATE desktop in dit geval. Hetzelfde geldt dus blijkbaar voor rclone, maar dat heb ik nog nooit geprobeerd.

De parameter “use_locks” op 0 zetten in /etc/davfs2/davfs2.conf geeft in ieder geval als resultaat dat files die naar de cloud gekopieerd worden daar ook terecht komen. Blijkbaar zit daar een probleem.