I recently upgraded to Audacity 3.0.2 on my Mac mini (M1, 2020) running macOS Big Sur 11.2.3, and I can no longer work on projects that live on a network drive. I can open .aup projects, which get converted to a .aup3 project upon opening, but when I try to save it to a network drive, the .aup3 file gets deleted right after saving. I can save the .aup3 file locally and move it to the network drive, but I can’t open it from the network drive, because I get the error as noted in the screenshot.
The only workaround seems to be moving files to my local drive before opening them, and then moving them back to my network drive after finishing. This is feasible to do in the mean time because I have a 10gbit connection to my NAS, but I’m hoping it gets fixed soon.
Happy to provide any other info to help diagnose this, thanks!
You may have been lucky in the past, but it has always been risky to run an Audacity project on a network drive. Recording to a network drive is particularly risky as network drives do not guarantee how long it will take to exchange data - if Audacity gets too far ahead of the drive, then data is dropped and the recording is trash.
Whether or not you can run Audacity 3.x projects on a network drive depends on how the drive is mounted and how it is formatted. FAT formatted drives are no longer supported. Other formats (including NTFS) are supported, provided that it is mounted in a way that allows a secure SQL connection.
Future versions of Audacity “may” support insecure SQL connections, though this will not be recommended (but may be useful to some users on fast home networks).
Thanks for the info. I never realized working off a network drive was technically unsupported. It is mounted as an SMB share, and on the NAS side, it’s a striped+mirrored zfs pool. I’ve worked on hundreds of .aup projects (digitizing vinyl records) that never had any issue on the old format.
2.1. Filesystems with broken or missing lock implementations
SQLite depends on the underlying filesystem to do locking as the documentation says it will. But some filesystems contain bugs in their locking logic such that the locks do not always behave as advertised. This is especially true of network filesystems and NFS in particular. If SQLite is used on a filesystem where the locking primitives contain bugs, and if two or more threads or processes try to access the same database at the same time, then database corruption might result.
It may be worth playing with the system to see if you can persuade it to work, but you could be up against some complex technical limitations. If you do get it working, please do post back and let us know how.
does the file ‘appear’ for a moment in the file system and then disappear again?
Much more likely the file name appears in the system without the actual file. When the system cleans up, it realizes its mistake and, well, cleans up. I don’t think the file was ever there.
You’re a celebrity unicorn. We had a poster who set up his machine to record both sides of a Skype call for his podcast and happily cranked out show after show. Nobody else on earth can do that and he’s looking at the rest of us like we’re nuts.
I know you’re saying to yourself “What difference could it possibly make for a simple file transfer?” The answer is none, but that’s not the problem. When Audacity sees a drive, it naturally assumes the drive can be used for such tasks as overdubbing where it has to play a backing track to the performer at the exact same time it has to record the performer’s fresh work.
This is a piffle for most internal drives and you can sometimes force an external or local network drive to do it. Internet or cloud drives are large and convenient, but laughably sloppy.
The first time somebody converts their land-line telephones to Voice Over Internet, there’s an immediate complaint of delays and hitches in the words and conversations.
Now try to do a multi-track musical overdub session that way.
Hi, thanks for getting back to me. It appears this problem only appears when I try to save a .aup3 after importing a .aup file. Please see: https://youtu.be/_ontIoG9v0o. For the brief moment the file is there, the file size reports as the same size as the same .aup3 saved locally.
There is no error message in this case. The file appears in the file system and then disappears almost instantly.
When I try to save an existing .aup3 (from a local drive) onto a network drive from audacity, I get an error as expected (see screenshot)
With Audacity 3+ not recognising FAT drives, this has simply made Audacity useless to me.
I have been using Audacity to create radio programs for years and have had no problems using FAT drives.
Most of my work is stored on an external FAT HD drive.
I now can’t even get an mp3 file from a FAT drive into Audacity.
This change has simply made Audacity useless to me except in versions before Version 3.
I would have recommended Audacity to anyone before.
I can’t do that now.
Audacity doesn’t support opening projects from a FAT drive, or saving projects to a FAT drive. There are no such restrictions regarding importing or exporting audio files.
FAT is a very old file system and has limitations that do not affect more modern file systems. For example, FAT16 has a 2GB or 4GB file size limit, and FAT does not support secure SQLite connections (the latter being a major issue for AUP3 projects).
You “should” be able to copy or move a saved project to a FAT drive once the session has been closed, but you would need to move or copy the project back to a more modern file system before opening it again. Can you do that?
As above, that must be a different issue, so better to start a new topic with a full description of what happens when you try.