Mounting error after upgrading to wheezy - Changes in mount.cifs from 4.5 to 5.5?

[Philipp Flesch]

Hi from Munich,
we have some special issues with the current cifs-utils (5.5) in=20
Debian Wheezy.

A lot of our (raw) logfiles are stored on a Windows 2008 R2=20
fileserver, while we use Debian to generate the reports.

The share is available as
\\fs01\Share

while the logfiles can be found in special subdirs
DepartmentA\Stats

We use a seperate user "stats_user" to access the files. This user has=20
no "listing-rights=E2=80=9C above the final "\Stats" directory.

Using Windows 7, everything works fine...
\\fs01\Share\DepartmentA\Stats can be directly mounted to an local=20
drive...

Using cifs-utils (4.5) in Squeeze everything works fine, too!
mount -t cifs //fs01/Share/DepartmentA/stats /mnt/DepartmentA_stats -o=20
user=3Dstats_user,domain=3Dxy,password=3D'xyz'
makes all files accessible from Debian.

Using the same mount-command with the same user, we got a "permission=20
denied".
Retrying with a default-user (with listing-rights) the subdirectory is=20
mounted without any errors...

Are there any big changes between 4.5 and 5.5 which can cause this=20
error? Is there a solution, to avoid the issue?

Thank you very much

Philipp

[Jeff Layton]

On Wed, 18 Dec 2013 14:10:17 +0100

Post by Philipp Flesch
Hi from Munich,
we have some special issues with the current cifs-utils (5.5) in=20
Debian Wheezy.
=20
A lot of our (raw) logfiles are stored on a Windows 2008 R2=20
fileserver, while we use Debian to generate the reports.
=20
The share is available as
\\fs01\Share
=20
while the logfiles can be found in special subdirs
DepartmentA\Stats
=20
We use a seperate user "stats_user" to access the files. This user ha=

s=20

Post by Philipp Flesch
no "listing-rights=E2=80=9C above the final "\Stats" directory.
=20
Using Windows 7, everything works fine...
\\fs01\Share\DepartmentA\Stats can be directly mounted to an local=20
drive...
=20
Using cifs-utils (4.5) in Squeeze everything works fine, too!
mount -t cifs //fs01/Share/DepartmentA/stats /mnt/DepartmentA_stats -=

o=20

Post by Philipp Flesch
user=3Dstats_user,domain=3Dxy,password=3D'xyz'
makes all files accessible from Debian.
=20
Using the same mount-command with the same user, we got a "permission=

=20

Post by Philipp Flesch
denied".
Retrying with a default-user (with listing-rights) the subdirectory i=

s=20

Post by Philipp Flesch
mounted without any errors...
=20
Are there any big changes between 4.5 and 5.5 which can cause this=20
error? Is there a solution, to avoid the issue?
=20
Thank you very much
=20
Philipp
=20

More likely, a change to the kernel and not cifs-utils is causing this
for you. What kernels do your working and non-working configs have?
Does it work if you mount with sec=3Dntlm ?

--=20
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+***@public.gmane.org>

[Philipp Flesch]

Hi Jeff,

Post by Jeff Layton
More likely, a change to the kernel and not cifs-utils is causing this
for you. What kernels do your working and non-working configs have?

(working) squeeze --> 2.6.32-5-686-bigmem
(non-working) wheezy --> 3.2.0-4-686-pae

Post by Jeff Layton
Does it work if you mount with sec=ntlm ?

sec causes same error ...


Greetings

Philipp

[Pierre Frenkiel]

Post by Philipp Flesch
Hi Jeff,

Post by Jeff Layton
More likely, a change to the kernel and not cifs-utils is causing this
for you. What kernels do your working and non-working configs have?

(working) squeeze --> 2.6.32-5-686-bigmem
(non-working) wheezy --> 3.2.0-4-686-pae

Post by Jeff Layton
Does it work if you mount with sec=ntlm ?

sec causes same error ...

hi,
I just see this mail now, coming back home...
I had a similar problem when kernel change from 3.2 to 3.10.
and found that the 3 following commands work:

mount -t cifs -o sec=none //wehd/hdd /d6
mount -t cifs -o "guest,sec=ntlm" //wehd/hdd /d6
mount -t cifs -o "guest,sec=ntlmv2" //wehd/hdd /d6

best regards,

[Steve French]

I doubt that the sec=3Dntlm would make much of a difference but would b=
e
interesting to see what the access denied is coming back on - since
from what you describe listing the contents of the root directory of
the share should be permitted to both users so this is not an access
denied on top of prefixpath issue as we had seen a few years ago.

Post by Philipp Flesch
Hi from Munich,
we have some special issues with the current cifs-utils (5.5) in Debi=

an

Post by Philipp Flesch
Wheezy.
A lot of our (raw) logfiles are stored on a Windows 2008 R2 fileserve=

r,

Post by Philipp Flesch
while we use Debian to generate the reports.
The share is available as
\\fs01\Share
while the logfiles can be found in special subdirs
DepartmentA\Stats
We use a seperate user "stats_user" to access the files. This user ha=

s no

Post by Philipp Flesch
"listing-rights=93 above the final "\Stats" directory.
Using Windows 7, everything works fine...
\\fs01\Share\DepartmentA\Stats can be directly mounted to an local dr=

ive...

Post by Philipp Flesch
Using cifs-utils (4.5) in Squeeze everything works fine, too!
mount -t cifs //fs01/Share/DepartmentA/stats /mnt/DepartmentA_stats -=

o

Post by Philipp Flesch
user=3Dstats_user,domain=3Dxy,password=3D'xyz'
makes all files accessible from Debian.
Using the same mount-command with the same user, we got a "permission
denied".
Retrying with a default-user (with listing-rights) the subdirectory i=

s

Post by Philipp Flesch
mounted without any errors...
Are there any big changes between 4.5 and 5.5 which can cause this er=

ror? Is

Post by Philipp Flesch
there a solution, to avoid the issue?
Thank you very much
Philipp
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs"=

in

Post by Philipp Flesch
More majordomo info at http://vger.kernel.org/majordomo-info.html

--=20
Thanks,

Steve

[Philipp Flesch]

Hi Steve,

I doubt that the sec=ntlm would make much of a difference but would be
interesting to see what the access denied is coming back on - since
from what you describe listing the contents of the root directory of
the share should be permitted to both users so this is not an access
denied on top of prefixpath issue as we had seen a few years ago.

Sorry, but perhaps I described the share-configuration not exact enough.
listing the contents is only allowed in the final (second) subdirectory,
but not in the root of the share and not in the first subdirectory:

no listing allowed \\fs01\Share
no listing allowed \\fs01\Share\DepartmentA
listing allowed \\fs01\Share\DepartmentA\Stats

Greetings

Philipp