Please support large files in smbfs by default

Bug #38886 reported by UbuPetr
26
Affects Status Importance Assigned to Milestone
samba (Baltix)
Fix Released
Undecided
Unassigned
samba (Ubuntu)
Fix Released
Wishlist
Unassigned

Bug Description

Making the current 'lfs' flag the default would enable large file support. (there may be reasons not to of course)

Original report: If we want to upload larger file than 2GB (2048 MB) through smbfs (mount -t smbfs) we obtained error message: File size limit exceeded! And operation failed with SIGSEGV error. If i tryed mount -t cifs, Ubuntu said to me that operation is not permitted, although I made it as root (sudo su).

Revision history for this message
barbolani (barbolani) wrote :

This seems to be a long standing problem with smbfs file system, as I've seen it happening in other releases. The thing is, you can get files with sizes over 2GB without problems using the command line tool smbclient.

Revision history for this message
Marcus Sundman (sundman) wrote :

Still "Unconfirmed" after 4 months?! I can confirm that it's in the newest dapper, with "smbfs v.3.0.22-1ubuntu3.1" and "linux-image-2.6.15-26-k7 v.2.6.15-26.46".

Revision history for this message
didier (did447-deactivatedaccount) wrote :

It's a smbfs limitation, cifs is the way to go. If mount -t cifs doesn't work double check you /etc/fstab options and fill a new bug, thanks.

Revision history for this message
Gilles (ubuntugc1) wrote :

What's interesting here is that uploading large files (100 Gb) onto a NAS drive using nautilus works fine (I suspect nautilus use the smbclient command) and that getting this same large file through the samba mount works!!

What does not work is trying to upload a large file through the samba mount (again download is fine!)...

So to me this would highlight a real bug rather than a limitation of the smb protocol (or if that's the case it is a really strange protocol that changes its data type depending if the message is incoming or outgoing!).

Now concerning cifs, yes it will most likely superced smb but I have to admit that at the moment I am still battling even more with it than I am with smb. Admittedly I wonder if my cifs issues could be a problem between linux and the NAS drive but I think it is the point: at present smb will still be more reliable and mature than cifs. So perhaps we should not ignore smb bugs just because cifs will a reliable replacement in the (far?) future...

Revision history for this message
Gilles (ubuntugc1) wrote :

Note: I did my tests using Ubuntu Edgy 6.10, kernel 2.6.17-10-generic, and samba 3.0.22

Revision history for this message
Adam Collard (adam-collard) wrote :

Passing the "lfs" option to mount allows files >2Gb to be transferred.

See http://kbase.redhat.com/faq/FAQ_71_4536.shtm for more information

Revision history for this message
Gilles (ubuntugc1) wrote :

Agreed. Using the "lfs" option, it worked. So the case should be closed.

The only thing remaining to do is perhaps the fact that the "lfs" option does not seem to be that well documented. Once you know the option, yes it is easy (google) but it is not so when you don't know the name of the option.

For example the man command does not even have any reference to "lfs", and using the "help" argument only brought a one liner "lfs - Long Filesystem" (at least on my system). It could be confused with long filename support.

I need to find out how to edit man pages at some point :-)

Revision history for this message
Marcus Sundman (sundman) wrote :

Other programs don't need any "do_not_break_my_files" flag to work properly, so why should smbfs, even if the option was well documented?
The FAQ entry at redhat (the link above) says that "the server that is being mounted with smbmount must be a Red Hat Enterprise Linux server, otherwise, this procedure may not work." This is written before it mentions the "lfs" flag, so I don't know how they are related. Anyway, if this works transparently (and properly) on windows then this should be possible also with smbfs.

Revision history for this message
Gilles (ubuntugc1) wrote :

The "samba/cifs" protocol has a part that is dedicated to negociate if large files are supported or not. The only thing is that the samba mount command will report itself has "not supporting large files" unless the "lfs" flag is used.

I must admit at some point I have been thinking of reversing the logic in the code and have large file support "on" by default (at least on the client side, the resolution will still occur, so if the server does not support it then there are no problems).

However, the best solution would be to check if there is a flag somewhere in the kernel indicating that large file support is currently activated. I will try to have a look. But, still, does anyone knows if this would cause problems? (I must admit I am still wondering why this "lfs" flag was used. There could be some reasons that we are unaware of...)

Revision history for this message
Henrik Nilsen Omma (henrik) wrote :

Large file support works with 'lfs' but is poorly documented and should perhaps e default behaviour.

description: updated
Changed in samba:
importance: Medium → Wishlist
status: New → Confirmed
Revision history for this message
Steve Langasek (vorlon) wrote :

Thank you for taking the time to report this issue and help to improve Ubuntu.

To my recollection, large file support in smbfs has always given somewhat inconsistent results, even when the 'lfs' option is specified. I agree that large file support should have been the default; but in any case, for Ubuntu 8.04 on, the smbfs driver has been obsoleted in favor of the cifs driver, which does not have this problem.

If you run into other difficulties with the cifs, please open separate bug reports for those issues.

Changed in samba:
status: Confirmed → Fix Released
Przemek K. (azrael)
Changed in samba (Baltix):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.