similar to: msdfs proxy question

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

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

Hey, thanks for the input! I am looking into that. It is however a bit complicated due to the authentication lines and share connect lines being only related due to proximity in the log. It would probably work for most of the instances, but it would not be 100% viable, meaning we would be getting compaints and questions from our user "I ain't got that share?! WTF!!" I was going to

Hi, I was wondering if someone had any thoughts as to why "preexec" doesn't fire when "msdfs proxy" is used? Thank you, Greg Enlow -- Greg Enlow grenlow at hk.mailbox.de On 13 May 2015, at 11:18, Greg Enlow wrote: ok ok ... Names have been changed to protect the inoccent. This installation is being used to mitigate a server migration by providing read-only access

Hi, Thank you for you input! We tried that already. That, however, doesn't do the same thing. It is then simply a DFS server and not the "magical" msdfs proxy - yes the user can now click on a link to get to the desired spot, but the proxy function _automagically_ sends the user, when they access the msdfs share, to the netapp's readonly share without the extra click. And it

On 18/05/15 07:36, Daniel M?ller wrote: > Msdfs proxy is pointing to another instance of samba servers, it passes > through. > I think running preexec there on the other instance will do the trick. > > Greetings > Daniel > > > EDV Daniel M?ller > > Leitung EDV > Tropenklinik Paul-Lechler-Krankenhaus > Paul-Lechler-Str. 24 > 72076 T?bingen > Tel.:

Hello, i got a msdfs share running and now i want to hide folders from users who got no access to them anyway. For example: List of shares: test1 test2 User sees only: test1 Is something like that possible mit samba itself or does someone know a workaround to get it running like that ? Thanks for any ideas. A.Dura

Dear all, I am testeing the dfs functions with Samba4. In my global section: host msdfs=yes vfs objects = dfs_samba4 Later on setting a dfs root: [dfs] path = /windows/dfs read only = No msdfs root = Yes ls -s the shares in this root. lrwxrwxrwx 1 root root 19 2. Dez 09:29 difaem -> msdfs:linux2\difaem lrwxrwxrwx 1 root root 20 2. Dez 09:29 leitung ->

Have a 2003 server located outside of the Domain network over a VPN. The server originally existed inside the network (10.1.1.0/24) but now exists on 10.10.12.0/24. I can access shares over the VPN to the domain controller, but when I try to log in as a domain user it says the domain is unavailable. I added the domain controller as a WINS server on the 2003 server. nbtstat -c on the 2003 does

Since past the beta-times of samba 4 (and it worked in former times!!) it never worked like this: \\yourdomain\share or \\yourdomain \dfs-share. The only thing working along witch your domain is: \\yourdomain\netlogon. I had another thread open on this case some times ago. Greetings Daniel EDV Daniel Müller Leitung EDV Tropenklinik Paul-Lechler-Krankenhaus Paul-Lechler-Str. 24 72076 Tübingen

Hello, everyone, I'm seeing some inconsistent behavior across SMB clients when configuring shares using the "msdfs proxy" parameter, and was hoping to get some advice from the community on this. My issue is that various SMB clients seem to behave differently when this parameter is pointed as a path that includes a sub-folder under the root share. So, given the following share

Just an idea: Why dont us msdfs just pointing to the netapp with ln -s msdfs: And in the smb.conf ex: [netapp] root preexec= yourscript path=yourpath msdfs root=yes 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

Hi, I am trying to configure domain DFS (I think that's the correct term) as below, using the guide on the wiki: https://wiki.samba.org/index.php/Distributed_File_System_(DFS)#Configure_domain-based_DFS_in_Samba I am aware that the wiki says that this doesn't quite work... however it feels to me that it's very close, nearly working, and I might be able to get it going (hopefully?!)

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

Hello, I have Samba server running version 3.0.33-3.29.el5_5.1. The Samba server is a member server of a Windows 2003 domain. Winbind provides authentication. We have a physical directory named hr that is shared as "hr" and is accessible to the HR department. A subdirectory of the hr directory named hrshared is shared as "hrshared" and should be accessible to specific users

Well, this doesn't fix the preexec issue, but you might scan through the samba logs finding connections to the RO share, identify that IP address there, track back to Hostname and/or user who authenticated to that share and the use that as the basis for the email address. On Tue, May 19, 2015 at 12:38 PM, Greg Enlow <grenlow at hk.mailbox.de> wrote: > Hi, > > Thank you for you

Msdfs proxy is pointing to another instance of samba servers, it passes through. I think running preexec there on the other instance will do the trick. Greetings 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

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

There is a strange behaviour having two DCs joined in one Domain concerning the [home] share. The [home] is fixed on a replicating gluster volume on both DC. Now creating the users directory with ADUC ex.: \\s4master\home\%username% would do the necessary and the directory is created on both dcs. On the first DC all working fine without any issue but on the second the user cannot login their home

I'm dealing with a Linux environment with extensive automounting, that also has DFS configurations for the Windows clients of various CIFS systems. I've got CIFS automounting working for various CIFS servers, which definitely has its uses, but I'd *love* to be able to mount the DIFS published paths for the CIFS shares? Basically, if I have shares called \\example1\share1 and