[gdal-dev] VSI CIFS driver

Craig de Stigter craig.destigter at koordinates.com
Mon Dec 16 14:44:27 PST 2019


It was a good idea. We've been trying to make the FUSE thing work, but
there are a lot of hoops to jump through.

   - We did find `smbnetfs`, which is a *slightly* more updated package
   with seemingly more sensible usage information
   - Docker doesn't support it unless you have CAP_SYS_ADMIN:
   https://github.com/docker/for-linux/issues/321 - which defeats the
   purpose; we might as well just use `mount.cifs` at that point.

We're going to switch back to looking into implementing a VSI driver for
wrapping libsmb.

On Mon, 16 Dec 2019 at 15:41, Craig de Stigter <
craig.destigter at koordinates.com> wrote:

> Sorry, that's `fusesmb`, not `smbfuse`
>
> On Mon, 16 Dec 2019 at 15:40, Craig de Stigter <
> craig.destigter at koordinates.com> wrote:
>
>> 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>
>>
>
>
> --
> 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/20191217/22710381/attachment.html>


More information about the gdal-dev mailing list