similar to: msdfs links on multiple servers ?

Re-sending with right email... msdfs root is set to "no" by default and is per-share. [myshare] msdfs root = no path = ... Should do the trick. Otherwise if mounting on linux you can also use the 'nodfs' mount option (mount.cifs //host/share/... /mnt/ -o ...,nodfs) to disable DFS resolving and automatic sub-mounting. Chad W Seys <cwseys at

Chad W Seys <cwseys at physics.wisc.edu> writes: >> Yep, sounds like a bug indeed. You still have the option to edit the smb.conf >> on the server side if you want to use smb2+. > > Good to keep in mind. > I'm speculating leaving 'nodfs' out of smb2+ was purposeful. Originally > it was a workaround for Samba 3.something . Maybe the cifs authors were

(Let's keep this on the list) Aurélien Aptel via samba <samba at lists.samba.org> writes: > Chad William Seys <cwseys at physics.wisc.edu> writes: >> Somehow the destination having 'msdfsroot yes' prevents the cifs kernel >> module from following the link. I've taken a look at your traces and right off the bat I see things like this: [...]

Hi Chad, Sorry for the late reply. Looking at this now. Chad William Seys <cwseys at physics.wisc.edu> writes: > I've attached traces and logs of these situations: > > msdfs root = yes, link points to share, link CAN be followed > trace_msdfsrootyes_share.* > > msdfs root = yes, link points to path, link CANNOT be followed > trace_msdfsrootyes_path.* In this one I

Hello, >> Can more than one server have a share with 'msdfs root = yes'? Or >> can there be only one root? (Setting 'msdfs root = yes' on shares on > > yes Thanks! It works great for all clients* except the linux kernel (v4.9) mount, which was what led me astray. Any idea if this works in more recent kernels? If not where do I wish list this. :)

Hi all, Is 'msdfs root = yes' required in any share (along with 'host msdfs = yes' in global) where you'd like msdfs links to work (redirect the client)? Can more than one server have a share with 'msdfs root = yes'? Or can there be only one root? (Setting 'msdfs root = yes' on shares on more than one server seems to be working at the moment, but

> Which smb version are you using (mount option)? Support for DFS on smb2+ > was only added in linux 4.11. smbstatus shows the connection as NT1. DFS links do work like this: serverA_msdfsrootYES => serverB_msdfsrootNO But not like this: serverA_msdfsrootYES => serverB_msdfsrootYES Somehow the destination having 'msdfsroot yes' prevents the cifs kernel module from

The main change in this release is to address some regressions that crept in when we switched to a scheme that does not rely on walking /tmp to look for credcaches. We now will use the information from the kernel about the initiating pid, reach into that task's environment and scrape out the $KRB5CCNAME variable. This can be problematic in setuid situations, so we avoid doing that for the

On 02/03/16 20:12, Chad William Seys wrote: > Hi Rowland et al, > >>> The reason I thought sssd would be best is because I want to use the >>> /etc/passwd file for user existence and was easy to set up. >> You cannot have the same user in /etc/passwd and AD i.e. user 'foo' in >> /etc/passwd could, and probably would, be seen as the the AD user

Hi! For quite some time I'm trying to find what's going on with MSDFS referrals. Samba version is 4.19.6. We've global host msdfs = yes (the default anyway), and for a share in question, msdfs root = yes. testparam confirms the settings. There's a symlink created in the root dir of the share, which points to the same server but different path: dfstest =>

Hi Rowland, > Are you using sssd or nslcd ? I am using sssd. I can ssh into the server using credentials from either kerberos realm. E.g. ssh cwseys at PHYSICS.WISC.EDU@smb01.physics.wisc.edu (works) ssh seys at AD.WISC.EDU@smb01.physics.wisc.edu (works) PHYSICS.WISC.EDU is an MIT kerberos KDC. AD.WISC.EDU is a active directory KDC (etc). The reason I thought sssd would be best is because

Hi Rowland et al, > > The reason I thought sssd would be best is because I want to use the > > /etc/passwd file for user existence and was easy to set up. > > You cannot have the same user in /etc/passwd and AD i.e. user 'foo' in > /etc/passwd could, and probably would, be seen as the the AD user 'foo'. The way the system is set up, username existance and

Chad William Seys <cwseys at physics.wisc.edu> writes: > Kernel 4.13 can resolve either style of link, so I don't think we need > to spend more time with it! > gvfs in Debian 9 also works (as do Windows 7+ and Mac 10.12+). Good. I actually remember fixing something similar now, ha. If you cannot update your kernel I think disabling the unix extension might be a workaround (-o

Hello list, I am trying to get a DFS share to work here, linking to a few Windows 2000, XP and NT machines. Using Samba 3.0.6 on Debian. I followed the instructions in chapter 17 of the official HOWTO collections and set it up like this: [global] ... netbios name = fileserver host msdfs = yes [dfs] path = /home/data/shares/postdfs valid users = @post force group = +post read only = No force

On 01/03/16 23:16, Chad William Seys wrote: > Hi Rowland, > >> Are you using sssd or nslcd ? > I am using sssd. I can ssh into the server using credentials from either > kerberos realm. > E.g. > ssh cwseys at PHYSICS.WISC.EDU@smb01.physics.wisc.edu > (works) > ssh seys at AD.WISC.EDU@smb01.physics.wisc.edu > (works) > > PHYSICS.WISC.EDU is an MIT kerberos

Hello list, we have two samba servers on two localities with bigger distance between them. On both localities there are organizational staff working. And I am trying to configure homedirectories for all of staff in this way: - all users will have same beginning part of URL path where is their homedir located (i.e. \\files.example.com\loginname) for unification and central acces - but because

On 07-06-2024 06:59, Michael Tokarev via samba wrote: > 07.06.2024 07:54, Jeremy Allison wrote: >>> msdfs is broken in 4.19.? It worked fine in 4.18. > > This is not entirely true. > >>> Is no one using msdfs?? I wonder why I was the first to discover this? >> >> There must not be a test for your specific use-case. >> >> MSDFS is tested in the

Hi, After some experiment with MSDFS on Samba I have seen this problems and I don't know if this are caused by my possible wrong configuration or if are "feature" of MSDFS: -as described into the documentation I compiled a Samba version with --with-msdfs and this smb.conf (server 172.26.11.236). The configuration file is: [Global] host msdfs = yes [dfs] path = /mnt/disk

On 2/14/20 4:54 PM, Mike Pastore wrote: > I guess the question is: what are you streaming to? And if the answer is > streams_xattr, the question becomes: then why not just use > fruit:resource=xattr? When I tried fruit:resource=xattr appledouble files ._ were created. (I know I'm hung up on aesthetics.) Chad.

Why is that when you create a share, the default is 'msdfs root = yes'? Also, why is that a share that is set 'msdfs root = yes' -- or, rather, a share that does /not/ set 'msdfs root = no' -- advertises that it is a DFS root to the Linux CIFS client, /even /when 'host msdfs = no'? This sounds like A) a bug (ignoring 'host msdfs', and B) a misfeature (msdfs