similar to: Bug 12518 - smbclient -c 'cd <dir>; ls' for DFS generates STATUS_INVALID_PARAMETER

This issue is reproducible for this customer and a couple of others. We execute the smbclient command the same way for each instance. The null user name is valid syntax sent from the smbclient. When we send the command " smbclient -c 'cd <dir>; ls' ", samba code executes starting with Negotiate Protocol Request, and onward. I'm guessing this could be a DFS issue, but

"Tompkins, Michael via samba" <samba at lists.samba.org> writes: > I'm wondering if anyone else has any feedback on this or needs anymore info ? Can you provide the output of the failing command with full debug messages (-d10)? -- Aurélien Aptel / SUSE Labs Samba Team GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg,

Good Day, We experience the following when we have outages or perform disaster recovery exercises. Our DFS Shares come from a Windows cluster with 2 servers, each one in a different location. When the server that we have active connections to goes offline, the server has an issue connecting to the second server. This even happens under a controlled shutdown and startup situation. If we

> 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

(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: [...]

Good Day, We use a lot of DFS Shares (Windows) across our Linux Servers. The DFS Shares are setup in a Cluster. Over the weekend we did a DR excercise which included shutting down one of the Servers that hosted the DFS Shares. What we found is that any Linux Server that had associated itself with the DFS Server that was shutdown did not try and connect to the remaining Server that was up. Is

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

Hi, Is there a place where I can specify defaults options a for "mount -t cifs"? I would like to change the default protocol version to vers=2.1 Is there something like a cifs.conf or such...? MJ

Hi Aurélien, is there some documentation around where I can read about that? Where can I find the information, that I need Kernel 4.11 or above to get DFS with SMB2.0 / 2.1 / 3.0 and above working? Regards, Christian Am 12.06.2017 um 12:46 schrieb Aurélien Aptel: > Hi Christian, > > Christian Garling via samba <samba at lists.samba.org> writes: >> a few days ago we

Hi , I want to configure DFS on standalone server on HP UX IA 64. Could you please help me on this. Thanks.

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

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. :)

> > When you provide an exact vers= then no auto-negotiation happens (unless > you pass "vers=3" which essentially means 3.x: use 3.0 or above). You > either get the connection or mount fails. None the less, you can dump > the current SMB ressources managed by the kernel by looking at > /proc/fs/cifs/DebugData if your kernel is recent enough it should show > the SMB

On Mon, Sep 18, 2017 at 1:33 PM, Dale Schroeder < dale at briannassaladdressing.com> wrote: > > > Try the "vers=3.0" option. That's what fixed mine. > > I suspect my old version of cifs-utils doesn't understand that option. Note the output says "vers=3.0,ver=1": mount.cifs --verbose //192.168.254.35/projects /mnt/smb -o

On Sat, 13 Jan 2018, Rowland Penny wrote: >> I have a samba file server that I created about 20 years ago and in >> the time I have done the little updates needed to new server (when I >> move to a new server I copy config and adapt if needed). >> It only do public file sharing. >> >> Some weeks ago a client stopped to connect to the share. >> Only this

Does os x (10.13) support negotiation of unix extensions/CIFS? When hard links didn’t work I dug in and while I found info on CAP_UNIX, and added ‘unix extensions = yes’ globally, the Negotiation makes no mentions: Negotiate Protocol Request (0x00) Capabilities: 0x00000077, DFS, LEASING, LARGE MTU, PERSISTENT HANDLES, DIRECTORY LEASING, ENCRYPTION Negotiate Protocol Response (0x00)

On Tue, Apr 03, 2018 at 12:09:52PM +0200, Aurélien Aptel via samba wrote: > Dan Janowski via samba <samba at lists.samba.org> writes: > > > [ Unknown signature status ] > > Does os x (10.13) support negotiation of unix extensions/CIFS? > > > > When hard links didn’t work I dug in and while I found info on CAP_UNIX, and added ‘unix extensions = yes’ globally,

On Mon, 15 Jan 2018, Aurélien Aptel wrote: > "Barbara M. via samba" <samba at lists.samba.org> writes: >> Anyway, tried your hint. >> No difference for the specific win 10 client. Still can't connect. >> All other Win 10 and the 2016 tested still works as usual. >> smbstatus still reports the "strange" rows: > > Try looking at a

> > I tried looking at the network capture using `tcpdump -A -X` but wasn't > able to understand anything. I tried installing wireshark on a throwaway > cloud instance, but realised that it's a GUI program. Can you please help > be with the network trace at > https://www.dropbox.com/s/r8cn0qggrvmrpc3/dump.pcap?dl=0 ? It's capturing > the network chatter for ~1min

Hello list, a few days ago we migrated our shares to a DFS cluster, also we disabled SMBv1 protocol. Now we are no longer able to connect to the shares with our linux workstations. The setup looks like this: linux workstation -----> AD server (Windows Server 2008 R2) -----> file server (Windows Server 2016, running in 2008 R2 compat mode) I have searched the web for a solution on the