Wrong or negative disk space in large SMB mounts, "not enough free space"

Hi,

MacOS 10.4 and perhaps earlier sees large SMB mounts as having incorrect or, which is crazier, negative disk space. It's an obvious signed integer overflow. E.g.:

$ df -h .
Filesystem Size Used Avail Capacity Mounted on
//XXX;xxx@xxx/xxx 973G -1.9T -1.2T 225% /Volumes/xxx

It doesn't seem to be an inherent problem of the SMB protocol as MacOS X 10.5 can correctly recognize and report the terabytes for the same SMB share:

$ df -h .
Filesystem Size Used Avail Capacity Mounted on
//XXX;xxx@xxx/xxx 5.0Ti 2.1Ti 2.8Ti 44% /Volumes/xxx

Windows XP has no problems with the share either as verified with Explorer and "dir".

The server s/w in my case is Samba but it shouldn't really matter.

The most annoying consequence from the bug is that Finder refuses to copy files to the share as it tries to check if there is enough free space in the destination volume beforehand.

Are there any immediate workarounds known for the issue, at least to make Finder copy work?

Thanks!

Yar

MacBook Pro, Mac OS X (10.4.11)

Posted on Jul 6, 2009 11:37 PM

Reply
5 replies

Jul 8, 2009 1:26 PM in response to yarique

This is a very common problem with SMB and volumes over 2TB in size.

The problem isn't limited to Mac OS X. All version of Samba, and even early versions of Windows had the exact same problem (the original protocol was written when 2TB was an unimaginable amount of disk space (640KB of ram, anyone?).

It does appear to be fixed in 10.5 - Apple included a later version of Samba that can deal with it, but the earlier versions still suffer.

There's no simple workaround other than to either upgrade the client (I've never tried building/installing the Samba client on Mac OS X 10.4) or to rework your file shares so that they're under 2TB.

Jul 14, 2009 11:16 PM in response to Camelot

Camelot,

Sorry, but you seem to confuse Samba in particular and SMB at large. Samba is an SMB server software, it runs on a FreeBSD box in my case and all clients but MacOS X 10.4 are happy with it. (My field technicians report that even Windows 98 can access the 5TB share OK.) From this it is obvious that the bug is in MacOS X 10.4 SMB client code.

My current workaround is to switch the users affected to WebDAV. The disk space shown is still not quite correct (WebDAV limitation?), but at least Finder can copy files to the share OK.

Yar

Jul 17, 2009 12:48 AM in response to BDAqua

Sorry, but can you guys tell a client from a server and a protocol from its implementation? Camelot keeps telling his favorite tale about inherent 2TB limitation in the SMB protocol while it is clearly the MacOS client that had been broken until 10.5 came out.

Answering my own question, as usual:

Fortunately, Samba (the server-side thing) can compensate for broken clients with this handy option <[http://us1.samba.org/samba/docs/man/manpages-3/smb.conf.5.html]>:

max disk size (G)

This option allows you to put an upper limit on the apparent size of disks. If you set this option to 100 then all shares will appear to be not larger than 100 MB in size.

Note that this option does not limit the amount of data you can put on the disk. In the above case you could still store much more than 100 MB on the disk, but if a client ever asks for the amount of free disk space or the total disk size then the result will be bounded by the amount specified in max disk size.

This option is primarily useful to work around bugs in some pieces of software that can't handle very large disks, particularly disks over 1GB in size.

A max disk size of 0 means no limit.

Default: max disk size = 0

Example: max disk size = 1000

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Wrong or negative disk space in large SMB mounts, "not enough free space"

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.