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>
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
