Ben
My feedback
28 results found
-
macOS: support "Access devices by name" (mDNS/Bonjour) for LAN connections, like Windows already has
2 votesAn error occurred while saving the comment Ben
shared this idea
·
-
18 votes
An error occurred while saving the comment Ben
commented
*Feature request*
Please add a setting that lets the user choose where Proton Drive's macOS cache and/or mount root lives — for example, a folder on an external volume rather than the system disk.*Background*
The macOS Proton Drive client uses Apple's File Provider framework. This forces both the visible mount (~/Library/CloudStorage/ProtonDrive-…-folder) and the underlying blob cache (/private/var/folders/<hash>/T/com.apple.fileprovider.ffp/…) onto the boot volume, with no documented way for the user to relocate either.*Why this matters*
For users on Macs with a small internal SSD and a large external drive for media, documents, and archives, this is a hard blocker. Every file synced to Proton is duplicated locally as cache on the internal disk, so the practical sync ceiling is "whatever fits on your boot volume" — not "whatever you have on the external drive you actually store data on."iCloud Drive, Dropbox, and OneDrive all have the same limitation because of Apple's File Provider design. Proton has an opportunity to differentiate by offering control here, which would directly benefit users with external-storage-based workflows (creatives, developers, archivists).
Ben
supported this idea
·
-
432 votesBen
supported this idea
·
-
2 votesBen
shared this idea
·
-
5 votesBen
shared this idea
·
-
6 votesBen
supported this idea
·
-
622 votesBen
supported this idea
·
-
46 votesBen
supported this idea
·
-
148 votesBen
supported this idea
·
-
1,533 votesBen
supported this idea
·
-
15 votesBen
supported this idea
·
-
37 votesBen
supported this idea
·
-
2,209 votesBen
supported this idea
·
-
1,343 votesBen
supported this idea
·
-
32 votesBen
supported this idea
·
-
2,097 votesBen
supported this idea
·
-
107 votesBen
supported this idea
·
-
27 votesBen
shared this idea
·
-
659 votesBen
supported this idea
·
-
2,968 votes
Proton and Standard Notes are joining forces: https://proton.me/blog/proton-standard-notes-join-forces
Ben
supported this idea
·
Update: found a workaround that's better than IP address - appending .local to the hostname (e.g. *mydevice.local* instead of *mydevice*) resolves via mDNS and connects instantly, even with Proton VPN connected.
Tested across 3 configs:
Allow LAN on with split tunneling off,
Allow LAN on with split tunneling on (app excluded),
and Allow LAN fully OFF with split tunneling off.
The .local resolution worked in all three, including with Allow LAN disabled entirely. Only the bare hostname (no .local suffix) still fails with error 0x104, same as originally reported.
This suggests the VPN tunnel doesn't actually intercept mDNS/multicast traffic (224.0.0.251) at all, regardless of the Allow LAN setting - it's unicast DNS specifically that gets routed through the tunnel and fails to resolve local hostnames. So native "access by name" support may just need the client to try mDNS/.local resolution instead of relying on plain unicast DNS for the bare hostname.
Leaving the request open since Proton support (ticket #5116245) described this as an unsupported gap with no timeline, but documenting this for anyone else hitting the same issue in the meantime.