Samba File Server and Docker

Dan Seguin dan.seguin at
Tue Mar 10 07:32:14 UTC 2020

From: Dan Seguin
Sent: March 10, 2020 2:44 AM
To: Andrew Bartlett; Dan Seguin
Subject: Re: Samba File Server and Docker

From: samba-technical <samba-technical-bounces at> on behalf of Dan Seguin via samba-technical <samba-technical at>
Sent: March 10, 2020 2:25 AM
To: Andrew Bartlett; samba-technical at
Subject: Re: Samba File Server and Docker

From: Andrew Bartlett <abartlet at>
Sent: March 10, 2020 2:14 AM
To: Dan Seguin; samba-technical at
Subject: Re: Samba File Server and Docker

On Tue, 2020-03-10 at 05:59 +0000, Dan Seguin via samba-technical
> I'm writing a VFS module for a back end encryption and KMI system. I
> hope that I can provide something somewhat like the Scanner VFS does,
> i.e. an api for a plugable backend.
> I have a design in mind, not sure of the ramifications involving
> disconnected/reconnected sessions and statefulness.
> I hope there's interest out there on this, I'll outline how I'm
> approaching this.  I'll share what I have as things progress, and
> publish (if deemed solid).

I looked into this for a client a couple of years back, and I strongly
suggested that they use the kernel VFS or block layer encrypted file

The reason I say this is that is is quite tricky to do this right in
Samba, with complexity and issues similar to the recently removed
'write cache' code.

The challenges is that Samba clients expect to be able to:
 - seek to arbitrary file positions
 - read and write less than a whole block, and not on block offsets
 - do so safely from multiple clients where a write to position A and B
are safe and independent, even if they are in the same encryption

Of course, if your backend is already doing this and you just need to
interface to their userspace VFS interface, then go right ahead, just
don't blame Samba if the backend doesn't quite life up to the promises
it makes :-)

Andrew Bartlett

Andrew Bartlett             
Authentication Developer, Samba Team
Samba Developer, Catalyst IT

I understand.

My proposed design is that the shares (files) are "show only",  any open means if  "policy" allows, a decrypted copy is made to an isolated "session area", say a hashed username DOT subdir, the resulting "OPEN" call will then get the decrypted FD returned.

I'm only worried about the STAT calls in the FSP before any close.  Can I re-write the FSP filename for STAT/LSTAT/etc calls?

Hope this makes sense.

Apologies, I missed posting to the list: 

Further on this, is that once the client is done with this isolated file, on close, it will get encrypted, and an atomic rename to the "show only" area is done.

There is no file contention or locking, or any of that at this point: it's last man writing still wins, but at a macro level.  Advisory read locks via VFS would be respected before rename, of course.


What I'm not sure about is the FSP to client relationship. If I rewrite the asked for file (path/file, relative) in the request header (because I moved it), does the client use the "FSP" or will it ask for a STAT/LSTAT on the original path/file?  This is a state/context/session issue. 

Lend me your eyes, thanks. 

More information about the samba-technical mailing list