Hi,
I am on latest version (on a trial if that helps) 1.8.20 (103)
I am not able to write album art to files on a samba network share (flac files to be specific) I am able to change all the other tag properties however.
I get the following error trying to write album art, and a temporary folder named the same as the track and a postfix .sb- is created with a copy of the music track in it.
If I copy the files to a local directory it adds the album art without issue.
It looks like it maybe similar to this closed bug fix: Cannot Alter Files on Network Drive w/o Album Art
Just wondered if there is anything I can try or if I can do something to provide more info on this bug.
Can you try this command via Terminal.app while Mp3tag being closed:
defaults delete app.mp3tag.Mp3tag SecurityScopedBookmarks
After that, load the folder (not the individual files) via ⌘O and see if the issue persists.
If the problem still persists, BackLog is an option to get a more detailed insight into what might be causing the issue. Please set the process to Mp3tag and include all events that are not directly created by this binary.
The idea of this is to gather some information on what's causing the issue.
Thank you for the fast reply Florian. I have tried what you have suggested and unfortunately it has not made any difference.
I have noted that the file it creates in the temporary folder (I think it is actually a file and macOS is showing it oddly as when I copy it out it becomes a file) does have the image inserted correctly and does play without issue. So maybe it is failing to remove the original file.
I have downloaded BackLog and captured the logs for an example session where the tagging breaks, the log is uploaded here : Mp3Tag MacOS BackLog (u3ox57wc) - PasteCode.io
Thank you for the log. Your analysis of the issue is correct — Mp3tag is creating a temporary file when tagging FLAC whenever the existing padding in the file (= reserved space for future changes) is too small to take the change. This often happens when adding cover art.
Because the file resides on an SMB share, Mp3tag can't use atomic rename and tries to 1. create the temp file, 2. remove the the original file, and 3. rename the temp file to the original name.
The log shows that step 2, deleting the original file, fails in this case due to error
NSPOSIXErrorDomain Code=16 "Resource busy"
which is EBUSY.
Can you check if another process is accessing and locking the file on the original file system of the Samba share and, thus, preventing the file from being deleted?
Thanks for the info this has spurred me on to do more testing.
- I have restarted the file server where the shares are running on (no change)
- I have closed any processes locally that could interferer with files (no change).
- I have setup a NFS share on the server with a separate mounting path on the macOS workstation (no change).
- I ran the same operation on a different tagging program (Musicbrains Picard) and that did work.
I hope that helps, happy to test further.
Thank you for the additional testing!
Regarding MusicBrainz Picard: it might use a different approach which doesn't involve temporary files, but instead creates the new file in memory and rewrites in at the original location. In addition, it's not a sandboxed application.
Can you share which server you're using? Also, can you — after creating a backup of the files — try deleting the files from Finder and copying the backup to the original location?
Ok, I have made some progress.
On a totally different mac (2016 Intel Macbook Pro) accessing the same network share via the same method. It works fine without issue. So this must be something specific to the machine I am on (Mac Mini M1). So I can at least rule out the server side of the config / share settings.
I have tried disabling more services and still no progress, I am using a custom window manager (yabai) so maybe this is the issue, I am going to try and pair this back further. If there are any tips on further troubleshooting what could be locking files locally that would be much appreciated. Granted I do not think this is a problem with the software but my configuration. I am however incredibility grateful of your help and support.
Edit: -
I have ordered myself an external nvme to boot the M1 Mini from with a clean install of macOS (saves me the pain of not reinstalling if it makes no difference) so hopefully in a day or so I can do a clean test from the same hardware.
I have now had a chance to test it on the same hardware (M1 Mac mini) with a fresh install of latest macOS. The only items installed were mp3tag and backlog (outside of standard install).
Connecting to the same SMB share it is very strangely producing the same error. I am most confused, I was sure it was some software installed that was causing this. I have a new set of logs but I have no idea how to proceed.
https://pastecode.io/s/ggixuiom
Thank you for doing these additional and extensive tests! I'm also surprised -- it seems that newer macOS (compared to the 2016 Intel MPB) has a different SMB driver, which has some unexpected interplay with the server you're using.
- Can you share which server you're using?
- Can you — after creating a backup of the files — try deleting the files from Finder and copying the backup to the original location?
I've just tested this again with latest macOS Sonoma 14.4.1 on a SMB share on a Synology running DSM 7.2.1-69057 Update 3 with the latest SMB Service installed and everything works as expected.
Hi, I don't mind doing the tests, it frustrates me when it does not work and I enjoy getting to the bottom of things! And.... I have a resolution to the issue and can replicate the problem at will now!
Ok so it is some odd combination of the different driver, introduced some point after macOS Monterey (as that is the latest version that the working hardware supports), possibly in Sonoma. And a specific fruit:locking option (fruit:locking = netatalk) that is part of the vfs_fruit module for SMB (it makes SMB play nicer with macOS).
I ended up spinning up another VM on my proxmox server and just testing new clean samba configs. Started with a copy of my normal file share config and then removed all the vfs_fruit settings (which then worked) and added them back until it fell over again. A bit more testing and I was able to insert the line and break it on two different servers.
I still don't quite understand why the NFS share did the same thing but that is thought for another day.
For the assistance of anyone else that finds this I will give a breakdown of hopefully relevant versions of server software etc.
Mp3Tag Version: 1.8.20 (103)
Server
OS: Ubuntu 22.04.4 LTS
Kernel: 6.5.11-7-pve x86_64
Samba: 4.15.13-Ubuntu
Client:
Hardware: Mac Mini M1
OS: macOS Sonoma 14.4.1
I would also once again thank you so much for you excellent help with this, it is not often you get such direct and helpful support with software. I will as you may expect be purchasing it right now!
Many thanks for those tests and sharing your findings! I've now also reproduced the issue on latest Ubuntu with fruit:locking = netatalk. As soon as this is changed back to the default fruit:locking = none everything works again.
I've checked the Samba wiki and it also doesn't use netatalk in its recommended settings. However, the vfs_fruit man page uses it in its example section.
Thanks again for your help and the kind feedback and for supporting my work!
No problem, glad we managed to get it resolved, plus if anyone else now comes across this same issue they know how to fix it!
Very happy to support you the software is great, well priced and the support is fantastic!
