Why do I get error that filenames longer than 31 characters are unsupported?

There are certain characters which are illegal in Mac files names, there are others which are best avoided. Older software could be using older programming interfaces which have the 31 character limit but certainly Apple Mail, and Apple's own built-in print to PDF option should be using the latest programming APIs and not have this limit.

These older programs not only had a filename limit, but also an entire filepath limit, i.e. the length of all the folder names as well as the file name added together.

I can remember when Microsoft Office for Mac suffered this limit you could find a file in the Finder, double-click to open it which would work, but when you tried to save it Word or Excel would complain because the filepath was too long. A workaround was to save it say to the users desktop and then drag it in to the folder that was a sub-folder of a sub-folder of a sub-folder i.e. a long filepath.

Another historical problem was when Macs running very old software tried to access a more modern Mac server and the older Mac would force a translation to a shorter name. This could happen with Windows client to a Mac server as well.

With regards to the question by CSound1 if you did list an example file name and perhaps ideally also the full entire file path with all folder names, we can see if any potentially problematic characters are included.

Hi Leslie,

This has happened a couple of times to me. One of them, I paid Apple for a support call and then summarily forgot what we did to fix the issue. Yesterday, I repaired permissions on my main "drive" (an SSD) and ran disk utility on it, and the problem resurfaced. I don't know if that had anything to do with it, but it seems suspect.

In any event, I went into the invisible "Library" folder/Preferences and moved the com.apple.finder.plist file to my desktop to force the OS to rebuild it, believing that perhaps the finder preferences file had become corrupted somehow. And, this seems to have solved the problem. To access this hidden folder:

HD > Users > Your Name > Library (now hidden; accessible by using Option key while clicking on Go in Finder menu which will unhide it.

I have this bug when saving a Mail.app message as RTF to the Desktop. I have tried moving ~/Library/Preferences/com.apple.finder.plist out of its directory. But when I then launched Mail.app again, the same bug persisted.

Hi Everybody,

I have the same problems, too. Saving pdfs in mail (attachments) and exporting pdfs from pages is only working with filenames < 31 chars. Saving in another path (randomly) helps sometimes. As far as I know it occours after updating to 10.9.2. But I'm not sure.

Hope a patch will come to solve this....

I have exactly the same problem. It seems to have occurred after the upgrade to 10.9.4.

Drag and dropping the mail attachment to the same local folder, works.

This clearly is a bug.

I'm on 10.9.2 and just got pretty much the same problem while using Firefox, saving a file I printed and saved to pdf. It had been working fine saving to the hard drive and then I thought, why not make an alias to make it easier to find. So I did. The next time I printed and saved to pdf to the alias version of the same folder, I got the 31-character error. I then tried to save to the original folder and it worked just fine. I will try it again after rebooting, but I suspect this has more to do with pointers in the OS than anything else.

I tried rebooting and it fixed the problem at least for now. Interesting.

Just to post what I had to do when this suddenly started happening to me. I rebooted but the problem persisted, so I duplicated the Pages document that was giving me the error and exported to PDF from the new copy and it worked fine. Then I went back to the old copy and tried it again and that worked too. Very odd.

I have a new Macbook Pro with OS X 10.9.4 and have experienced the same problem with Mac mail. When I shortened up the initial filename, it appeared to save but I couldn't find the file in the destination folder. I did a Spotlight search and found the file saved in ~/Library/Containers/com.apple.data/Data. I have no idea what the Mail app is doing to achieve this result. I hope Apple does something about as a real fix -- not just suggest rebooting.

I have also started to see this problem when I try to save attached pdfs from 'Mail'.

I noticed that it happens when I try to save to a particular folder (which was previously fine and has other files with the same basic file name structure in it).

I created a new 'untitled folder' and copied the previous contents into it. I then tried to save the problem pdfs again - all fine. However, when I renamed the 'untitled folder' to something more useful the problem returned.

As a workaround I now have an 'untitled folder' as a place to save the attachments and then I move them into the folder that has a useful name. Seems happy enough with the file name if you do it that way.

I just had the very same problem using Safari - Print (Open PDF in Preview) - Saves As from Preview on Mavericks 10.9.4.

Initially selecting my target folder for the PDF in Preview resulted in

"Names longer than 31 characters are not supported on the destination volume."

I then selected the top-level Macintosh HD icon on the sidebar of the Save requester, navigated back to the very same folder and voila - save worked. Same filename (32 chars long, just letters, one underscore and .pdf as suffix), same location, but after 'resetting' the path in the Save requester...

I know this issue for quite some time, never posted about it; normally just save on Home or Root folder (which also means selecting an entry on the left sidebar in the save directory; never needed to reboot); also can't promise whether my approach is a permanent fix. Perhaps I simply took long enough while navigating in this save requester to trigger a timeout or whatever.

This bug is around for quite some time in Mavericks.... Typically it's transient.

PS: HDD is formated HFS+(Journaled) and is the standard boot device "Macintosh HD".

PPS: Thinking about it, I think I renamed the target folder via Finder before I did this Print as PDF - Save As process, but Preview was still running and I had saved previously into the folder with the old name. Perhaps this error message is simply a misleading symptom for an incorrect internal state of the save requester after the previous save path changed?

Let me pile on: Just had this problem for the first time on my late 2008 unibody MacBook, 10.9.4, Main HD with Mac OS Extended (Journaled). S.M.A.R.T.-status: SMARTOK

App: TextEdit

File: .rtf

Action: Save

No funny characters, have of course lots of files with longer filenames 😝

My german error message (which is the exact translation of Leslies):

Namen mit mehr als 31 Zeichen werden auf dem Zielvolume nicht unterstützt.

Bitte wählen Sie einen Dateinamen mit höchstens 31 Zeichen.

After 3rd or 4th try it just worked 😕

(I saved all console log messages including the string "textedit" from the time this happened, should I post them?)

Let me add one more incident identical to the one described in Leslie's original post. I just experienced it in Safari trying to Print/Save as PDF... I have been saving similar files on a monthly basis for over 5 years in the same file name format and character length (these are repeat transactions I save monthly as pdfs) and this is the first time I've received this error message. Clearly, this is NOT a problem with the target drive or folder.

The workaround suggested by floyd42 worked for me.

Everyone in this thread has experienced this error in Mavericks. I am running the most current Yosemite Beta 10.10, so they haven't fixed it yet. It is still intermittent even in the beta. I've successfully saved identical files with the same number of characters in the file name to the same target folder on the same target drive while running 10.10.

I experience the same issue on my Macbook Air. The suggestion by floyd42 works as well as saving files to the Downloads folder.

From there the file can be moved to the target folder where I originally wanted to save the file to.

FYI, I'm running version 10.9.4 (13E28)