IOException.ErrorNumber = 13

Targets macOS
#1

I have a client using my app that is attempting to use it on macOS to write small text and PDF files to a server via smb protocol. He says intermittently an error message displays. Looking at my code this is triggered from:

IOException.ErrorNumber = 13
IOException.Message = “”

I’m not sure if he’s attempting to write to a folder or a file name with non-ASCII characters. For starters I just wanted to know what the error number 13 is. Looking at the following error list (which I’ve found in other Xojo forum posts) I’m not sure what framework I should be looking at as there are so many listed.

OSStatus.com

Is anyone familiar with this error 13? Any info would be much appreciated. Thanks

#2

My guess is that it is a permissions error.

Kernel
errno.h EACCES
13 Permission denied

You can confirm this by checking folderitem.isreadable and folderitem.iswriteable.

#3

Thanks Sam. I can confirm that my app returns false for folderitem.iswritable when the client attempts to write a file to this network drive. I removed the check code that used folderitem.iswritable because of the comments I found in this Xojo forum post.

Either way, my app is able to write to a local drive and the user is able to copy the files to the network folder using the Finder. Do you know if an app like Finder can have different permissions compared to a different app? As in, is there anything one needs to do within a Xojo app to allow it to write files on a network drive using smb protocol? I’m not familiar with different network protocols, I’ve only read that smb was created by Microsoft so I’m not sure if that’s somehow an issue writing a file from a macOS app.

#4

Which version of macOS does the user have? Did he/she click okay on the stupid “Do you want to allow access to folder xyz?” Or did the user accidentally click on “not allow”? I also had some very odd reports by users for my own app where the app suddenly has no write access anymore on it’s own Application Support folder.

#5

If your customer is running macOS 10.15 or newer, your application may not have permission to access network volumes.

If you use App Wrapper 4, select “Capabilities” from the sidebar.
Under the “Files and Folders” heading, add a message to the “Network Disks” icon. Something like “So App can read and write files on network volumes”.
Also make sure you have “Hardened” selected in the sidebar.

Your customer may have already been asked and declined, in which case the customer must open “System Preferences”, go to “Security & Privacy”, Click on the “Privacy” tab, scroll down the left list and select “Files And Folders”, scroll through the right hand list to find your application and then check “Networked Volumes”.

#6

Thanks Beatrix and Sam. Good point on the macOS 10.15+ wrapper settings and/or system prefs settings which I had not thought about. However, word just back from the client is he’s running macOS 10.13.6 and the folder path he’s attempting to write to only contains ASCII characters and no spaces.

My app is created with Xojo 2019r1.1, wrapped with AppWrapper 3.11.3, is hardened and notarised, although I get the later is more for apps running on macOS 10.15+. The client is responsive to trying test builds, so happy to add some test messaging if that would help diagnose what’s going on here.

#7

You could try wrapping that code in a try-catch and then in the catch block write the file to the local disk first and then copy it to the network drive. It’ll be slower, but it may work.

It’d be helpful to know more about the drive though. Is it really a Windows server or just a Linux box running Samba for instance. If it’s the latter (which I suspect), knowing the config would would be extremely helpful as we might be able to replicate it.

#8

Thanks @Greg_O_Lone. Nice idea on the catch block however my apps write to files in multiple locations and it would be quite a job to either update all of these in all apps, or even better write a common method to handle this that they all call.

I’m waiting to hear back from my client on his setup and will forward it on once I have it.

#9

I agree with @Greg_O_Lone suggestion here, and ashamed I didn’t think of it myself, especially when considering that almost all saving done in my apps is done atomically.

I ask the macOS for a temporary location to create the file, the file data is written out to that temporary location, if it successfully writes the data, I then ask the macOS to replace the original file with the temporary one.

The Apple API I use will give you a temporary location per drive, but I’ve never tested it with a network drive, so I don’t know how that would work.

#10

Hi @Greg_O_Lone, my client is using a FreeNAS running Samba. I asked him to test all file exports from my app and found that PDFs and XLS files that use MBS plugins are able to write to this server. The files that can’t be written use either a BinaryStream.Create or TextOutputStream.Create.

Let me know if need more information on the server. If so, please be specific as possible as I have no experience on this front. Many thanks, Mark

#11

What you’ll need to do is get the samba config for the shared folder you’re having trouble with and then file a case in Feedback. Redacted for passwords of course, but just replace with ###### or something. We need that config as close as possible to the actual running version. It would also be helpful to know what the Linux permissions are on the folder that’s being shared.

Remember, all I’m offering is that we might be able to reproduce it and come up with another workaround. Fixing is another matter. If this truly is a permission thing, it may be a bad behavior between macOS and it’s samba driver. Keep in mind that samba is being emulated on both sides of this equation.

#12

Okay thanks @Greg_O_Lone for clarifying. The client’s IT guy gets back on the 12th. I’ll post a feedback once I have what you requested.

#13

I’ve logged this on Feedback with server details: 64378 - IOException.ErrorNumber = 13 when saving file from macOS to FreeNAS running Samba

#14

For what it’s worth (and I’m not even sure I’m in the right context, as I’ve not re-read the entire thread), I can reproduce an issue that looks similar with my NAS, from MacOS: as soon as I navigate to a folder having docx or xslx documents (Word or Excel), I can’t unmount the volume (it’s reported as “in use”).
The reason is a bug in QuickLook/Samba, where QuickLook, just by reading the file to generate the preview, won’t release the handle. Once you force-quit the QuickLook process, the volume becomes unused.

That is to say, the MacOS has bugs with QuickLook on Samba (and even other than this example).

1 Like
Forum for Xojo Programming Language and IDE. Copyright © 2021 Xojo, Inc.