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 < [email protected]> wrote: > 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> > -- 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
