The Samba-Bugzilla – Bug 3184
smbfs: smbmount(8) man page does not mention lfs option
Last modified: 2005-10-21 17:12:21 UTC
a forwarded bug:
In order to have LFS support on SMB-mounted shares, one must include
the "lfs" option to smbmount, but the latter is not documented in the
smbmount man page.
Please document it.
(Why enabling lfs support is not the default is beyond me...)
another comment on this bug (see URL above) is:
I found this bug report quite interesting, as I had already discovered
that although both my Linux systems and the Win2k file server support
large files, I was unable to create a large file on the smbfs mount.
I researched this further, and I discovered that mount.smbfs does
indeed have the undocumented 'lfs' option. However, the option is
anticipating future improvements to the smbfs kernel module. The
mount command queries the module to determine whether or not it has
LFS support and ignores the option if it doesn't. I checked the
source of the module, and it indeed does not have LFS support. Due to
that, the option is rather useless at this point. I suppose it would
be a good idea to just enable it (by default) since it is only applied
if the kernel has the capability, but I also suppose it doesn't matter
as long as the kernel lacks the capability.
I have dealt today with a number of minor issues in respect of the smbfs support
documentation, however, I do feel this is a waste of time given that smbfs is a
dead project. It is far more productive to put effort into CIFSFS which is a
project that has a future and that is being actively maintained. We actively
recommend people to use CIFSFS and not smbfs. I suspect that in the not very
distant future the support utilities for smbfs will be removed from the Samba
If you wish to provide me with XML patches to the source documentation I will
gladly apply them, but I am disinclined to spend more time on this than I have to.
I am open to further discussion, and to being convinced regarding documentation
updates, but want to use my time wisely.
- John T.
See previous comment.