Available Space is 0 bytes although plenty free

JD shared this problem 9 years ago

My "iTunes Media" folder is located on a NFS share.

I have been using TuneSpan to relocate media from other locations in the iTunes Media location - so far without problems.

Now TuneSpan is complaining that "Available Space" is 0 bytes on the span location, although there is plenty of space available on the share.

Some details:

Span location: /shared/media/iTunes Media

df (and all other tools) show plenty of space on the volume:

Filesystem 1024-blocks Used Available Capacity iused ifree %iused Mounted on

elwood:/export/media 515930552 409348280 80372800 84% 93639 32674361 0% /shared/media

Is this a bug?

Replies (10)


Could be a permissions issue.

First, I'd recommend going into the "File Access" menu within the "TuneSpan" menu in the menubar and removing access for this special location, which you can do in the locations submenu.

Then, get fresh access to the same location from the options in that menu.

Please let me know how that works.

It's also making me think I should make a "Refresh Access" option for these menu items...

It could also be an actual file system level permissions issue. I'd recommend taking a second look at all your file permissions on the network drive if refreshing TuneSpan access doesn't help.


Thanks for your response and support.

Unfortunately, none of that applies.

I checked/tried the following:

1) Permissions on /shared/media/iTunes Media are fine. The directory (and everything below it, is owned by my user. Owner-Write-Bits are set. I can create/modify/delete files there from Finder and Terminal without problems.

2) I followed your advise and cleared all "File Access" within TuneSpan. Then I re-added access to /shared/media/iTunes Media (see screenshot).

(Note that the access is marked Readable & Writable).

3) Finally, I've selected the above path as the new span location. But again it shows "Available Space: 0 bytes" (see original screen shot).

Please note that this has worked before in this configuration.

May this be related to some "miscalculation" of the available space due to some counter overflow? The only change I'm aware of is a recent resize (growth) of the /shared/media NFS volume.

Any other hints how to analyse this issue?


Because of Sandboxing, TuneSpan can only access stuff that is guest readable and writable. If your user is admin and that's the only way the drive is readable and writable that may not work for TuneSpan since it isn't allowed to function with admin access.

I would try opening up full read write access to your drive as a test to see if that works better for TuneSpan.


Hmm... I'm not able to follow that thought.

If Sandboxing would require guest (!) read/write access, this would never have worked before, and if this would be a general rule for Sandboxing, none of the other Appstore apps would work with my NFS shares.

And yes, my user is an admin - and always was.

However, I don't understand your statement that "TuneSpan [...] isn't allowed to function with admin access". Why not? Is has so far...!

In case I'm totally missing the point here, it would be quite helpful to understand the underlying principles. Could you elaborate on this or point to some information about that?


Basically, no Sandboxed apps can do anything that would require the admin password be typed in. Apple just doesn't allow Sandboxed apps to request admin access.

That may not be what we're running into here, but just to rule out a permissions issue, I figured it would be easy to open up full access and see if that makes a difference before trying to hunt down other issues.

Also, TuneSpan excludes the last 100MB of available space on every drive to be sure to never fully fill up any drives to help avoid some issues that can occur when drives are full.


At first I couldn't really tell what was what from the "df" listing you posted because of the line breaks (and I was out of my house, replying on my phone, so I couldn't dig deeper into how df displays its info and also to convert the bytes), but is it showing that only 80MB are available?

That would in fact show up at 0 bytes available in TuneSpan because of the last 100MB being excluded from the display of available space.


After some long absence from iTunes, I now reengaged with TuneSpan and promptly bumped into the same issue I've already reported 2 years ago.

Any of the previously posted advises where without effect, so I investigated again in this issue to finally find a potentially cause for this problem.

Brief revisit:

My iTunes media is located on "/shared/media/iTunes Media" which is located on a NFS-Volume which is auto-mounted (via OSX autofs) to "/shared/media".

This setup works just fine over years now. But TuneSpan has its trouble with it.

Trying to span any content from other locations to the NFS-based iTunes Media directory is not possible with TuneSpan, because it falsely assumes that 0 bytes are available on the Volume.

Pico mentioned earlier that anything below 100MB will actually show as 0 to protect the volume from filling up. Actually, that doesn't apply here, because the volume has approx. 45GB free space.

After experimenting a bit, I may have found the cause:

When I mount that NFS-Volume manually to "/tmp/media", TuneSpan now shows available space. However, the location shows as "iTunes Media (on SSD Mac)" with "Available Space on SSD Mac: 50 GB". It has obviously no notion that it is located on a dedicated (NFS-)Volume with different free space (45 GB).

At least it shows available space and allows spanning to that volume.

For reference:

$ df -k /
Filesystem   1024-blocks      Used Available Capacity iused               ifree %iused  Mounted on
/dev/disk1s1   249854256 194498824  52595500    79% 2165934 9223372036852609873    0%   /
$ df -k /tmp/media
Filesystem           1024-blocks      Used Available Capacity iused    ifree %iused  Mounted on
elwood:/export/media   673012864 627965824  45047040    94%  111927 90094319    0%   /private/tmp/media
Now with the automounted volume:

The automounter sits on "/shared" and mounts Volumes dynamically as defined in the automounter config. So accessing the path "/shared/media" mounts the NFS-Volume to that directory. In fact, that volume is effectively never unmounted due to constant usage.

Choosing "/shared/media" as the span location shows up as "iTunes Media (on shared)" with "Available Space on shared: 0 bytes". As before, TuneSpan seems to incorrectly determine the available space from the located shown in the brackets ("shared").

For reference:

df -k /shared
Filesystem      1024-blocks Used Available Capacity iused ifree %iused  Mounted on
map auto_shared           0    0         0   100%       0     0  100%   /shared
I assume, that is the cause for the "0 bytes" available space!

For me, this boils down to a problem how TuneSpan determines free space. It obviously has problems to use the correct volume.

With using the "/tmp/media" location, TuneSpan should notice that this is NOT the local "SSD Mac" volume but a mounted (remote) volume.

With "/shared/media" actually the same thing. The available space should have been determined from the mounted volume "/shared/media" not "/shared", which is a special local directory occupied by the automounter.

Any chance that this will get fixed in TuneSpan?


I'm so sorry I never got back about this.

I believe this should be fixed in TuneSpan 1.4 which I just released on the Mac App Store. You can get it here: https://mas.tunespan.com

I'm hoping this issue should be fixed since I made changes to always use the highest level mount point for a path instead of using the first (lowest level) mount point that is found for a path.

Please let me know if you're still running into any issues with TuneSpan detecting how much free space is on your NAS.


Hello Pico,

I revisited TuneSpan now, since you reported that this problem is resolved with 1.4. As it appears, it isn't :(

I'm starting with adding "File Access" to the required span location of "/shared/media/iTunes Media" which is a directory located on a NFS share (mount point: /shared/media). That directory is owned by my user and full read/write access is given.

However, adding that "File Access" seems to have no effect other than it being listed under "Locations access this run" with a details popup showing again the 0 bytes available (see attached screenshot). It is not listed as a span location, and even choosing it explicitly as a new location shows absolutely no effect or error.

Could you please fix this, or make TuneSpan more failure tolerant!? I actually don't care if it shows "0 bytes available", if it just would use the directory.


I'm so sorry this issue still hasn't been fixed.

Firstly, about adding the folder via the File Access menu not adding it as a span location, that is normal behavior. The File Access menu is just that. A record of what TuneSpan has access to and an advanced way to grant TuneSpan access to specific locations. It's an advanced usage menu, not intended to be how Span Locations are selected. To set a span location, drag the folder onto the Span Location area from Finder, or click the Span Location area and use the popup menu.

TuneSpan is currently checking all the mount-points and finding the highest level mount-point that the folder it is examining resides in.

Would you mind sending the current full output of "df -k" so that I could see all of your mount points? It may help me understand what TuneSpan is doing wrong here.

Leave a Comment
Attach a file