On Fri, 2006-01-27 at 18:20 +0100, Christian Perrier wrote:
Quoting Peter Eisentraut ([EMAIL PROTECTED]):
Am Donnerstag, 26. Januar 2006 17:50 schrieb Christian Perrier:
Should it then be tagged upstream wontfix and voilà?
Are the upstream developers aware of the issue?
Maybe or
Am Donnerstag, 26. Januar 2006 17:50 schrieb Christian Perrier:
Should it then be tagged upstream wontfix and voilà?
Are the upstream developers aware of the issue?
Quoting Peter Eisentraut ([EMAIL PROTECTED]):
Am Donnerstag, 26. Januar 2006 17:50 schrieb Christian Perrier:
Should it then be tagged upstream wontfix and voilà?
Are the upstream developers aware of the issue?
Maybe or maybe not...but my understanding is that all code related to
smbfs is
Steve Langasek wrote:
But an ill-designed one; refusing to allow mounting over a directory
that you own but don't currently have write access to, when other
filesystems have no such requirement, is unnecessarily inconsistent.
What is this inconsistent with? If you own a directory but don't
On Thu, Jan 26, 2006 at 11:00:40AM +0100, Peter Eisentraut wrote:
Steve Langasek wrote:
But an ill-designed one; refusing to allow mounting over a directory
that you own but don't currently have write access to, when other
filesystems have no such requirement, is unnecessarily inconsistent.
Steve Langasek wrote:
On Thu, Jan 26, 2006 at 11:00:40AM +0100, Peter Eisentraut wrote:
Steve Langasek wrote:
But an ill-designed one; refusing to allow mounting over a
directory that you own but don't currently have write access to,
when other filesystems have no such requirement, is
On Thu, Jan 26, 2006 at 11:19:55AM +0100, Peter Eisentraut wrote:
Steve Langasek wrote:
On Thu, Jan 26, 2006 at 11:00:40AM +0100, Peter Eisentraut wrote:
Steve Langasek wrote:
But an ill-designed one; refusing to allow mounting over a
directory that you own but don't currently have
Steve Langasek wrote:
No, they are not. User mounts are a well-established concept, and
smbmnt behaves inconsistently with respect to them.
I agree that the case you showed is broken. In that case, root has
implicitly granted fiddling permission in the given directory through
the fstab
I'm not satisfied with smbmount's behavior, and really never have been. I
don't think it'll ever be fixed in smbmount (as opposed to in mount.cifs),
but that doesn't mean it's not a bug.
Should it then be tagged upstream wontfix and voilà?
On Thu, Jan 26, 2006 at 05:50:17PM +0100, Christian Perrier wrote:
I'm not satisfied with smbmount's behavior, and really never have been. I
don't think it'll ever be fixed in smbmount (as opposed to in mount.cifs),
but that doesn't mean it's not a bug.
Should it then be tagged upstream
On Thu, Jan 26, 2006 at 05:42:45PM +0100, Peter Eisentraut wrote:
Steve Langasek wrote:
No, they are not. User mounts are a well-established concept, and
smbmnt behaves inconsistently with respect to them.
I agree that the case you showed is broken. In that case, root has
implicitly
tags 177584 upstream wontfix
thanks
Quoting Steve Langasek ([EMAIL PROTECTED]):
On Thu, Jan 26, 2006 at 05:50:17PM +0100, Christian Perrier wrote:
I'm not satisfied with smbmount's behavior, and really never have been. I
don't think it'll ever be fixed in smbmount (as opposed to in
reopen 177584
thanks
Package: smbfs
Version: 2.2.3a-12
Kernel: 2.4.19
The smbmount command fails if the mount point does not have write access
(i.e. 700 or greater). This is different than other mount types which will
work fine on a directory with permissions of 555.
13 matches
Mail list logo
