QField android app: Support SAF Storage Access Framework to avoid need for import/export - Allow R/W from LAN network storage (NAS, smb etc)
Describe the issue
Not an issue but a feature request - could not find it mentioned on the repo or qfield doc.
It would be nice to allow the users of the QField android app to open a project which is stored on a LAN server storage - eg a NAS (network attached storage) volume or network mapped drive.
There are some android File Explorer apps that allow you to connect to network drives (NAS shares, or via the samba protocol), but these apps wont allow mapping that remote location to a folder on the emulated storage - for example to a QField imported data directory.
If QField itself could allow reading/writing to a network share, this would make it easier to have a project synced locally - without relying on QField Cloud, especially important for projects of a few dozens of GB of raster data.
Hey there, is there any interest for this feature from the community or team? Otherwise, feel free to close, no regrets!
I "package for QFIeld" on desktop, writing to Nextcloud. On android, I use the + in local files to import from folder, and specify the project's folder. Then after using the project, I export to folder.
Are you suggesting a feature "use this directory as a project" after which it would read/write directly from that directory, without needing to import/export? If so that sounds useful.
If not, I didn't understand what you are asking for.
Thanks for the feedback, interesting use-case - relying on a cloud storage to share the qfield project. Indeed, with that flow it would be useful to remove the need from import/export when using a directory as project - although your description is already a very useful alternative!
What I had in mind was something that could rely on rclone - with which you can mount a network location (eg SMB file share) and map it to a partition on any OS - to mount the remote location, and have QField source a project from that mapped location on android. Unfortunately, Round Sync or RCX only let you visualize and do directory operations within their own application and won't map that rclone remote to a directory on the device, that could be used directly as-is by the QField app. So I don't see for the moment a workflow to use projects on Network Attached Storage that serve files usually via SMB. Edit some are mounting remote to file-system on android via rclone this way, which requires root, magisk module and tasker. Also possible RSAF is part of the solution since RCX and RoundSync cannot mount remotes for security reasons.
I don't understand what you are trying to do, or why what I suggested wouldn't be the way you would do it, once you had bits somehow in your phone's filesystem (SAF) view.
RSAF is definitely the way to go. This is the first app I stumble upon that does let me map my network folders (samba shares stored on NAS boxes) to the android SAF view indeed, without relying on alternative software like nextcloud to do the sync. So we can either
- close the thread considering the method provided solves the LAN access - could be useful to mention this workflow in the QField docs anyway
- or let it open as a feature-request to use the directory as project.
Thanks again for your help!
I find your comment odd, that using some app that does SMB and presents as SAF, is somehow less 'relying on alternative software", compared to the nextcloud app that does DAV and presents as SAF.
I would suggest that you close this and open a fresh issue to ask for QFIeld to adopt a directory in SAF so that there is no need to import/export..
Thanks again for the suggestion.
Regarding Nextcloud vs RSAF, it's just that Nextcloud is not running on the NAS, so I cannot use the nextcloud android app to access its directory and files, and hence qfield project - unless it can connect to a dedicated SMB share. I needed to access files on a NAS box that do have SMB setup, with already a few dozens PCs (windows, mac, linux) accessing the shared storage. Nextcloud is too resource-intensive for my use-case, especially given the current setup and my specific use-case.
I'll open the dedicated feature request and close this thread!
I'll leave this thread open but indeed rename it, looks like the history/background around why SAF support would be great for QField helps understand the feature request.