Bug 4645 - smbmount no longer allows to set smbfs group/permissions
smbmount no longer allows to set smbfs group/permissions
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: samba (Show other bugs)
6.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-08-21 23:05 EDT by v.kuhlmann
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-08-31 10:49:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description v.kuhlmann 1999-08-21 23:05:36 EDT
samba + samba-client 2.0.5a-1 (update)

It used to be possible (2.0.3a, RH 6.0) to set the
group and permissions for files and directories with
someting like
	smbmount ... -c "mount -g smb -d 700 -f 600"
This is still stated in the man page, but smbmount no
longer has a -c option. smbmnt is even less featureful -
other than the required -s option it has nothing useful in
terms of options.
The current smbmount seems to have reverted to the behaviour
of RH5.x, without however having -g -d -f.

Another thing is that for the past so many years the
smbfs/smbmount has a very strong tendancy to assign dates
like 1917 to files/diretories. This causes a lot of problems
later as these dates are illegal under Unix.
Comment 1 Bill Nottingham 1999-08-23 12:17:59 EDT
Yes, this was changed in samba; as such, we probably won't change
it back. Sorry.

I haven't noticed strange timestamps here with it, though.
Are you mounting NT server filesystems with the Win95 workarounds
enabled in the kernel?  That could cause strange timestamp
behavior...
Comment 2 Bill Nottingham 1999-08-31 10:49:59 EDT
We probably should have mentioned  that the command line options
did change in the advisory, yes.

As for the Win95 workaround/NT conflict, this should be fixed
with kernels >= 2.2.10, as they enable/disable the workarounds
automatically on a per-share basis.

Note You need to log in before you can comment on or make changes to this bug.