[gdal-dev] VSI CIFS driver

Craig de Stigter craig.destigter at koordinates.com
Sun Dec 15 18:40:21 PST 2019


I haven't quite exhausted my frustration budget for this yet but here's
what I've found so far:


   - `smbfuse` appears to be abandoned since 2007, though Ubuntu is still
   packaging it through 19.10.
   - I can't really find anything else in this space.
   - To use FUSE at all you need the `fuse` module, which isn't enabled in
   any of the default images I tried.
   - Some systems don't seem to support loading kernel modules, e.g. the
   xhyve VM on Docker for Desktop (well, the Mac version anyway) doesn't seem
   to allow `modprobe`

I think it's probably more straightforward to implement a VSI CIFS than a
FUSE CIFS.



On Sat, 14 Dec 2019 at 20:42, Craig de Stigter <
craig.destigter at koordinates.com> wrote:

> Thanks Even
>
> That sounds like a possible path forward, although it works for FUSE
> filesystems only, so we'd have to find a good FUSE implementation of CIFS
> (currently we're using the kernel provided cifs)
>
> If anyone can recommend a well-maintained FUSE CIFS implementation I'd
> gladly look into it. After some googling I don't see much that fills me
> with confidence, but I will continue to search at work next week.
>
> I'll keep you updated  on what I discover. Thanks
> Craig
>
> On Fri, 13 Dec 2019 at 23:38, Even Rouault <even.rouault at spatialys.com>
> wrote:
>
>> Craig,
>>
>> > We have to access some customer data via their CIFS shares on a regular
>> > basis.
>> >
>> > To date we have been doing it via a setuid script which mounts and
>> unmounts
>> > the CIFS share locally, then treats the files as local. We're
>> > containerising our workers, and using kernel mounts is no longer
>> possible
>> > (at least, not even slightly securely.)
>>
>> Is upgrading to Kernel 4.18 an option ?
>> See https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.18-FUSE
>>
>> >
>> > This means we need a userspace CIFS implementation for a lot of our GDAL
>> > code, and a VSI CIFS driver would seem to be the right thing to do.
>> > Presumably it will be a fairly thin wrapper of libsmb.
>> >
>> > 2. Would it be something GDAL might accept as a core contribution, or
>> > should we expect to maintain it outside of core?
>>
>> Hard to know where to draw the line. If recent kernels would make this no
>> longer needed, then its value in core might be low.
>>
>> > 3. We noticed https://github.com/OSGeo/gdal/pull/1289 should allow VSI
>> > plugins to be registered from Python,
>>
>> It allows VSI plugins to be registered with a C interface. So if you'd
>> want ot
>> use that from Python, you'd likely have to play with ctypes or similar
>> technology.
>>
>> > Are there any docs on how to actually do this?
>>
>> Well, the Doxygen docs of VSIAllocFilesystemPluginCallbacksStruct and
>> VSIInstallPluginHandler in cpl_vsi.h . And the tutorial you'll add if you
>> proceed that way ;-)
>>
>>
>> Even
>>
>> --
>> Spatialys - Geospatial professional services
>> http://www.spatialys.com
>>
>
>
> --
> Regards,
> Craig
>
> Developer
> Koordinates
>
> +64 21 256 9488 <+64%2021%20256%209488> / koordinates.com / @koordinates
> <https://twitter.com/koordinates>
>


-- 
Regards,
Craig

Developer
Koordinates

+64 21 256 9488 <+64%2021%20256%209488> / koordinates.com / @koordinates
<https://twitter.com/koordinates>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20191216/3c64f45c/attachment.html>


More information about the gdal-dev mailing list