[Samba] preexec and msdfs proxy

[Rowland Penny]

On 28/05/15 08:08, Greg Enlow wrote:
> Good Morning and thank you for your input.
>
> I had and still do understand what both preexec and root preexec do.  I had also and still do understand the paths you had explained.  I, however, had also already explained on 18 May 2015 15:31:55 CEST why your first solution was _not_ a viable option for us (server2 == NETAPP under warranty).  I had also already explained on 21 May 2015 22:41:17 CEST why option 2.) was an even _less_ viable solution due to the security permissions of the underlying NTFS system on server 2 then _not_ being user specific and therefore dangerous.
>
> I can understand and would accept that the 'msdfs proxy' mechanism might be executing at a time well ahead of the connect block in the code and therefore precluding any 'preexec' possibilities.  But it is exact that question that hasn't been answered - is this by design or a mistake?  If it by design, then so be it.  I would then confer with my superiors whether or not we ould be willing to take the risk of modifiying our NETAPP and possibly endanger its warranty.  If it is, however, an error then there is hope that the function 'preexec' might be repaired in a timely fashion, which would be a great help to us.
>
> Regards,
> Greg Enlow
>
> --
>
> Greg Enlow
> grenlow at hk.mailbox.de
>
>
>
> On 28 May 2015, at 07:51, Daniel Müller wrote:
>
> One more time:
> root preexec does: run a command or script if the user hit the share. Now
> with msdfs proxy it need to be run on the linked host that carries the
> share. So you are better
> to set root preexec on the share of the linked host. I think there is no
> other way.
>
> Server1
> [sharepointtoserver2]
> msdfs root=yes
> msdfs proxy =\server2\shareonserver2
>
>
> Server2
> [shareonserver2]
> Root preexec=.......................
>
> Or mount the shareonserver2  on server1!!!!
>
> Then do
>
> [shareonserver2mountedonserver1]
> Path to the mountpoint
> Root preexec= nowiwillwork
>
> Good Luck
> Daniel
>
>
>
> EDV Daniel Müller
>
> Leitung EDV
> Tropenklinik Paul-Lechler-Krankenhaus
> Paul-Lechler-Str. 24
> 72076 Tübingen
> Tel.: 07071/206-463, Fax: 07071/206-499
> eMail: mueller at tropenklinik.de
> Internet: www.tropenklinik.de
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: samba-bounces at lists.samba.org [mailto:samba-bounces at lists.samba.org] Im
> Auftrag von Greg Enlow
> Gesendet: Mittwoch, 27. Mai 2015 17:21
> An: samba at lists.samba.org
> Cc: Jeremy Allison
> Betreff: Re: [Samba] preexec and msdfs proxy
>
> Hi all,
>
> I was going to ask one more tine before I walk away sad and depressed - any
> hope on finding out why our installation won't fire 'preexec' with 'msdfs
> proxy' activated?
>
> 'til then!
> Greg Enlow
>
>
> --
>
> Greg Enlow
> grenlow at hk.mailbox.de
>
>
>
> On 18 May 2015, at 18:20, Jeremy Allison wrote:
>
> On Mon, May 18, 2015 at 03:31:55PM +0200, Greg Enlow wrote:
>> Hi,
>>
>> The Server to which the msdfs is pointing is a netapp. Though we
> theoretically can access the shell on it then begin to mess around there, we
> would really like to avoid that. Warranty and such make it a bit of a legal
> issue. That is the reason we went with a separate instance in the first
> place and now wonder why the preexec doesn't fire.
>> There is nothing in tmp of the msdfs box.
>>
>> Like I asked before, is this by design? If not what can we do to get
> around playing with underwear of our netapp?
>> Thanks!
> At the SambaXP conference all this week, but I'll try and find some time to
> look inside the code and let you know !
>
> Ping me again if I haven't replied by Friday :-).
>
> Cheers,
>
> 	Jeremy.
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> Zu buchen bei Hegel & Koch - http://www.hk-online.de
> ______________________________________________________________________
>
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> Zu buchen bei Hegel & Koch - http://www.hk-online.de
> ______________________________________________________________________
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> Zu buchen bei Hegel & Koch - http://www.hk-online.de
> ______________________________________________________________________
>
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> Zu buchen bei Hegel & Koch - http://www.hk-online.de
> ______________________________________________________________________

OK, as I said, I have never used msdfs, but from reading the 
documentation found from an internet search, it would seem that there 
shouldn't be anything in the share that diverts to another share but this:

[Drachenboot$]
msdfs root = yes
msdfs proxy = \realbigfs\Drachenboot_ro$

I get the feeling that everything else you added is ignored.
I also think that you need to add your 'root preexec' line to the 
re-directed share. What I think will then happen is, your client 
connects to the original share, it gets diverted to the new share and 
then whatever you have in the new share comes into force, including your 
script.

You could test this idea by creating a share on another samba server, 
point your original share at this and setup everything as I suggested, 
if it works, you will then know that it does work and will have to think 
how you get it work with your NAS.

Rowland