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:
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.
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.
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.
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”.
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.
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.
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.
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.
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
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.
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).
Hi @Greg_O_Lone, So I created a test app, had the client test it, got the client to provide the samba config and filed a feedback case #64378. It’s just been closed with the comment “13 is simply ‘permission denied’. That is really an error that the developer needs to deal with.”.
As the Feedback case is closed I have no way to ask if this setup was tested to check if Xojo is doing what it should or could. I get 13 is permission denied, but why is Xojo reporting this when other plugin functions in the same app can write to this folder and Finder can write to it?
I get if this is so obscure that it’s not worth Xojo looking into, but then why suggest creating a feedback case for it. Is this what you would expect from lodging this case?
Well I did not see the case. I’ll ask that it be reopened.
I just did a quick internet search and it appears that error 13 is not just a permission error, but one that may indicate that the volume couldn’t be mounted. Is it possible that the path points to a shared volume that requires a username and password and that info isn’t available when you open the FolderItem?
@Greg_O_Lone Thanks for looking into this. My released app exports multiple types of files in the one go including PDFs and text files. The PDFs created by the DynaPDF plugin can be exported to this share while text files created using a TextOutputStream.Create cause this IOException.ErrorNumber = 13. So I wouldn’t have thought that the problem was caused by the volume not being mounted or requiring a username and password.
Just out of curiosity, have you run this code to see which line the exception occurs?
in your example project you have a pretty simple example, but I can imagine that trying to set the ExtensionVisible property may just not be supported, and I highly doubt that the DynaPDF plugin does that either.
Dim t As TextOutputStream = TextOutputStream.Create(f)
t.Write "Test file data."
t.close
f.ExtensionVisible = True // Comment or remove this line
Okay fair points. I updated the test app and updated the code to remove the ‘f.ExtensionVisible = True’ and added code to show which line causes the exception in the MsgBox. I also added two new methods and associated buttons. The first does the same as the method above but in the try-catch it saves the text to a temp file (FolderItem.TemporaryFile) and then copies the temp file to the selected file on the server using FolderItem.CopyTo(f) (as you suggested). The second new method saves a PDF file using DynaPDF directly to the selected network folder. I built this test app with Xojo 2021r1 signed it and sent it to my client in Germany.
The client has already come back to me with screen shots of the results of all three tests. Button one (code above) shows the exception is triggered by the ‘Dim t As TextOutputStream = TextOutputStream.Create(f)’ when the file is saved to the network folder. The code works fine when the file is saved to a local drive. Button two has the same issue saving the file directly to the server but the creation of the local temp file and ‘CopyTo’ the network folder in the try-catch works. Button three was also able to save the PDF directly to the network folder.
My client confirmed that he doesn’t need to set a username/password to copy files to the network drive.
I see the Feedback case is open again so I’ll post the v2 test app project and screen shots from my client tests.
I think we’d have to confirm with Christian about that. It may be that DynaPDF writes locally and then moves it to the location you specify.
In which case, the share probably doesn’t allow or support the creation of writable file handles.
It has, but I have yet to be able to reproduce it. I have a samba server here to test with which doesn’t show the issue and haven’t found a way to virtualize a FreeNAS server.