Your message dated Wed, 13 Apr 2011 19:12:39 +0200
with message-id <[email protected]>
and subject line Re: cifs-utils: Can't mount shares of the type
<host>/<directory>/<sharename>
has caused the Debian Bug report #588305,
regarding cifs-utils: Can't mount shares of the type
<host>/<directory>/<sharename>
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
588305: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588305
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: cifs-utils
Version: 2:4.5-2
Severity: important
Hi!
Since version 4.5-2 of cifs-utils I can no longer mount shares which
contain a directory before the share name, e.g. //ds01.home/home/stse.
Calling mount.cifs with -vvvv I see, that the last part of the UNC path
is deleted (it tries to mount //ds01.home/home).
Shares of the format //ds01.home/data are working.
Downgrading cifs-utils to 4.1-1 solves the problem for me.
Shade and sweet water!
Stephan
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.34-Dom0 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages cifs-utils depends on:
ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib
ii libcap2 1:2.17-2 support for getting/setting POSIX.
ii libkeyutils1 1.4-1 Linux Key Management Utilities (li
ii libkrb5-3 1.8.1+dfsg-5 MIT Kerberos runtime libraries
ii libtalloc2 2.0.1-1 hierarchical pool based memory all
ii samba-common 2:3.4.8~dfsg-1 common files used by both the Samb
cifs-utils recommends no packages.
Versions of packages cifs-utils suggests:
ii smbclient 2:3.4.8~dfsg-1 command-line SMB/CIFS clients for
-- no debconf information
--
| Stephan Seitz E-Mail: [email protected] |
| PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html |
signature.asc
Description: Digital signature
--- End Message ---
--- Begin Message ---
Version: 2:4.9-1
On 04/13/2011 10:19 AM, Stephan Seitz wrote:
> Hi Luk!
Hi Stephan
> Thanks for your explanation.
>
> On Mon, Apr 11, 2011 at 07:38:49PM +0200, Luk Claes wrote:
>> Is a sharename containing a '/' what you meant by
>> <directory>/<sharename> or is it even something else?
>
> Well, it is a Windows share, so I don’t really know how it is configured.
> Maybe my explanation is not really correct.
>
> So let me try again:
> I have a server (e.g. home.local) with (probably) a share called home
> containing all user home directories. But a normal user doesn’t have
> direct access to the home directory, only to his own directory under
> home. So my service URI would look like //home.local/home/stse.
> This didn’t work with cifs-utils > 4.1.
>
> I now tested 4.9 and it works again, so this bug can be closed.
Ok, closing this bug.
> So now I only have two problems left but I don’t know if they are bugs
> in cifs-utils (tested with 4.9):
>
> - DFS mounts with kernels > 2.6.35 are not working;
Can you open a new bug for this one with an example mount command and a
clarification which part is the DFS link?
> - Kerberos and DFS mounts are not working really well together;
> - if your DFS name is your domain name (e.g. ads.local) pointing to
> the two servers dc1.ads.local and dc2.ads.local, trying to do a
> kerberos mount with //ads.local/ gives the error that there is no
> cifs ticket for ads.local. Using //dc1.ads.local/ it works. But if
> you have a share //dc1.ads.local/software where software is a link
> to //ds.ads.local/software no new kerberos ticket will be requested.
> (At least, so it seems).
This depends on DNS configuration AFAICT, it should work when DNS is for
instance configured like:
ads.local. A 1.2.3.4
A 1.2.4.5
dc1.ads.local. A 1.2.3.4
dc2.ads.local. A 1.2.4.5
4.3.2.1 PTR ads.local.
5.4.2.1 PTR ads.local.
What happens is that the ticket for ads.local should conceptually match
gethostbyaddr(gethostbyname(host)). In your case ads.local should match
gethostbyaddr(gethostbyname(dc1.ads.local)) or gethostbyaddr(1.2.3.4) in
the example which would be ads.local.
Cheers
Luk
--- End Message ---
