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 wetheoretically 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 getaround 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
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 wetheoretically 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 getaround 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 ______________________________________________________________________
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