Skip to contentSkip to conversation

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

DISCUSSION Philipp Flesch 4 participants 6 messages Dec 18, 2013 – Jan 16, 2014 3 messages not in the archive

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

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

A lot of our (raw) logfiles are stored on a Windows 2008 R2 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 no "listing-rights“ above the final "\Stats" directory.

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

Using cifs-utils (4.5) in Squeeze everything works fine, too!
mount -t cifs //fs01/Share/DepartmentA/stats /mnt/DepartmentA_stats -o user=stats_user,domain=xy,password='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 is mounted without any errors...

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

Thank you very much

Philipp

#1 lore raw
Quoted 30 lines · On Wed, 18 Dec 2013 14:10:17 +0100 Philipp Flesch…

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

A lot of our (raw) logfiles are stored on a Windows 2008 R2 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 no "listing-rights“ above the final "\Stats" directory.

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

Using cifs-utils (4.5) in Squeeze everything works fine, too! mount -t cifs //fs01/Share/DepartmentA/stats /mnt/DepartmentA_stats -o user=stats_user,domain=xy,password='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 is mounted without any errors...

Quoted 7 lines

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

Thank you very much

Philipp

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=ntlm ?

Signature · 1 line
Jeff Layton <[email protected]>

A message that is not in the archive (sent off-list or not yet received): 20131218114326.7f719964-4QP7MXygkU+dMjc06nkz3ljfA9RmPOcC@public.gmane.org

#3 lore raw

Hi Jeff,

Quoted 2 lines

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

Quoted 2 lines

Does it work if you mount with sec=ntlm ?

sec causes same error ...

Greetings

Philipp

A message that is not in the archive (sent off-list or not yet received): 52B1DDB7.3070909-3cc/[email protected]

#5 lore raw
Quoted 9 lines · Philipp Flesch

Hi Jeff,

Quoted 2 lines

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

Quoted 2 lines

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,

Signature · 1 line
Pierre Frenkiel
#6 lore raw
In reply to Philipp Flesch

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.

Quoted 40 lines · Philipp Flesch

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

A lot of our (raw) logfiles are stored on a Windows 2008 R2 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 no "listing-rights“ above the final "\Stats" directory.

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

Using cifs-utils (4.5) in Squeeze everything works fine, too! mount -t cifs //fs01/Share/DepartmentA/stats /mnt/DepartmentA_stats -o user=stats_user,domain=xy,password='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 is mounted without any errors...

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

Thank you very much

Philipp

--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 3 lines
Thanks,

Steve

A message that is not in the archive (sent off-list or not yet received): CAH2r5mv3yChbfKm0QBBZ=LymBx7Ssw6J_RmVMZQ1LJ8uDjLBuA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org

#8 lore raw

Hi Steve,

Am 18.12.2013 17:51, schrieb Steve French:

Quoted 5 lines

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