Sorry, that's `fusesmb`, not `smbfuse` On Mon, 16 Dec 2019 at 15:40, Craig de Stigter < [email protected]> 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 < > [email protected]> 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 <[email protected]> >> 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>
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
