I can imagine why mounting with serverino could made a difference. If
the server has broken support for returning serverinode numbers (or at
least for the specific findfirst level that returns search information +
server inode numbers) then things like resume keys could get messed up
which would
*** This bug is a duplicate of bug 286828 ***
https://bugs.launchpad.net/bugs/286828
If nodfs mount option works around the problem then this is a
duplicate issue, as suggested, and long since addressed. Remember,
there is a clear SERVER bug which has been fixed for quite a while, but
only
Simplifying:
1) older smbfs/smbmount had a bug: they didn't support DFS (which Windows
clients do, and Linux cifs client does) which is a critical feature of the
protocol in multiple server environments
2) Windows does not support Unix Extensions
Samba server introduced a bug (long since
OK ... doing a little more investigation it gets interesting to see what
crazy things gnome does (you can also try clearing the dmesg log and
then doing echo 7 /proc/fs/cifs/cifsFYI before you logoff/umount and
see what cifs operations are in dmesg)
What I see is that the slow operations are
running without umount.cifs (which is not needed unless you are doing
user mounts), the unmount finishes quickly, and with no visible errors
(the tree disconnection request times out fairly fast, and the rest of
umount proceeds fast after that)
--
CIFS/SMBFS shares not unmounted before network
The easiest way to test this is to always do umount -i mnt-point
rather than umount mnt-point unless you are doing an umount as a
regular user of a user mount (-i prevents the unneeded helper program
from being called)
--
CIFS/SMBFS shares not unmounted before network is shut down
On Tue, Dec 23, 2008 at 5:54 AM, Tom ttw...@gmail.com wrote:
After adding nodfs to my kernel at boot time did NOT change anything.
My MS Windows shares that use to mount automatically under 8.04 still do
not mount automatically after adding that option. Yet, after boot, I can
issue sudo mount
Just to summarize again:
1) A few versions of Samba server had a bug parsing DFS paths (fixed
in Samba server 3.0.26). You can see which version of server you have
mounted to by doing cat /proc/fs/cifs/Debug
Data on the client). When the Linux CIFS client added support for
DFS last year, those
Since the Samba servers 3.0.24 through 3.0.25a which exhibited this
problem may have had problems with parsing a DFS path (in this case
for a path based call to set the file server), could someone check if
the write problems go away if the mount is done with the nodfs mount
option (would require
The nodfs option was added by this patch:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2c1b861539c15491593625920058e06452cd3747
which went in right after 2.6.27 came out so will be in 2.6.28. The
patch is small and could be added to this 2.6.27 distro kernel
I looked at the wireshark trace in post #25 (by Alexey) and I see what
looks like a server bug in this old version of Samba (Samba 3.0.25).
Note that Samba 3.2.4 is current, and Samba 3.0.32 contains various
highly recommended fixes (Released in August Samba 3.0.32 is the latest
bug fix release
On Tue, Nov 18, 2008 at 9:55 AM, rylleman [EMAIL PROTECTED] wrote:
I can also confirm this bug.
One thing that might be of interest is the error message I get from KeypassX;
File could not be saved. The file could not be resized.
Can it be that there is nothing wrong with save itself but
.
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
CC: Stable [EMAIL PROTECTED]
Signed-off-by: Steve French [EMAIL PROTECTED]
commit 0752f1522a9120f731232919f7ad904e9e22b8ce
Author: Steve French [EMAIL PROTECTED]
Date: Tue Oct 7 20:03:33 2008 +
[CIFS] make sure we have the right
To make progress, we need data ...
Could someone please provide a wireshark (or tcpdump) trace of the
problem. See
http://wiki.samba.org/index.php/Capture_Packets
for step-by-step description (it is really not hard ... but without
this, we have no data)
--
CIFS share broken after upgrade
Probably not related - if you can get stack traces that would help
(e.g. echo t /proc/sysrq-trigger) at the time of a process hang
that would help to see what it is blocked on.
On the other question there are a pair of fixes to cifs in 2.6.27
which addressed a problem with directory searches to
The file save problem you mention is different than the automount
problem described earlier. In looking at the network trace of the
automount problem, I see that no traffic is sent on the network in the
failing case, which may simply be a configuration problem, or problem
locating mount.cifs
Unlike smbfs, Linux cifs client requires very little user space
intereraction unless you mount with Kerberos (sec=unix) or if the
server share is a DFS redirection to another server. The only user
space interaction other than that is translating host names to ip
address
On Sat, Nov 1, 2008 at
cat /proc/fs/cifs/Stats to see if there were any reconnections and
cat /proc/fs/cifs/DebugData to list the version information that the
server reports for this mount
If you can save a wireshark (or tcpdump) trace of the failure that
would be ideal and would allow diagnosing the problem quickly.
If disabling LinuxExtensions works as described above, there may be a
problem with the support for the Unix/Linux/POSIX cifs protcol
extensions on the device you are mounting (which is why it is important
to note the version information of the server as it is reported over the
network). Not that
Typo in the above (Not-Note)
Note that you can also disable Unix extensions on reasonably recent
Linux kernels by specifying nounix (as a cifs mount option)
Also note that you would normally not need to specify the default uid,
gid, and mode on the mount if the server and clients have the same
20 matches
Mail list logo
