Why does Safari not download files after Sequoia update?

macmustache wrote:

In our setup no files are saved to local disk; all files are saved to NAS.

You're gonna have to change that.

I do not know any reason why this function should be removed in Sequoia, especially since Ask for each download remains a choice in the settings.

I believe this is a bug in Sequoia Safari, not a problem of user practice.

Oh it's certainly a bug, but not one that's likely to be fixed. The problem lies with how the Mac works (or doesn't) with network volumes. There is a slight chance that Apple could fix Safari to save files differently, but it's only slight chance. This would be a quick and easy fix, so if it does happen at all, it might show up in 2-3 months.

The networking is a complicated, longstanding bug for many years. Quite frankly, I don't know how you managed to make it to Sequoia at all saving all files to a network volume. That's remarkable. I congratulate the skill and competence of your IT team. Alas, everybody meets their match eventually.

Sequoia is quite new, and probably most users are defaulting to the Downloads folder.

New or old, pretty much everybody uses the default Downloads folder on the local drive.

This is a pretty basic support problem. If Apple breaks something for 50 million people, that's Apple's problem to fix. But if Apple breaks something for 50 people, that's your problem to fix.

So, after the update to Seqoia, I began experiencing issues downloading music files to my external drive.

This drive is currently formatted EXFAT32.

To solve the problem, I connected a different drive formatted MAC OS Journaled.

Problem solved!!

I reformatted the troubled drive to MAC OS Journaled and I’m back to normal.

Hope this helps!

After three days of pulling my hair out since the update and not knowing why Safari can't move files after a download is initiated, I have come up with a solution. To clarify, I could not download any files from Safari since the Sequoia 15.4.1 update on my Macbook Pro 13-inch 2019. (Yes, apparently approaching dinosaur status!)

1. By miracle I was able to download the Brave browser, also when other downloads were not working. From here everything worked normally. I don't know why this download functioned, but I saved it to Macintosh HD -> Users -> my personal folder (my name)
2. I went back to Safari and changed the File Download Location to "Ask for each download."
3. I didn't before the upgrade nor do now have any extensions in Safari.
4. Now downloads are also working on Safari to this same file folder. HOWEVER, it still shows that it "can't move the file" in the downloads dropbox from the Safari Browser.

I hope this helps!

Check to see if your downloads folder is set to Downloads. Settings>General>File Download Location

I can confirm that downloads don't work properly when the download folder is on an SMB share.

Personally, I think this is actually great news. Maybe this will inspire Apple to actually improve their networking.

The behaviour that I'm seeing is identical to what I experienced around 2013 when building a bad idea of an app. I abandoned the app when I realized that Apple's networking stack just wasn't reliable. So, I went back to work and circa 2017 wound up at a place with an unlimited budget, great IT staff, and an unbelievably fast network. Still had Mac networking problems. I had to copy a file locally, make my changes, then copy the file back to the network. No way could I open a file directly on the network. I had to be careful with QuickLook too. That would lock up the system. I didn't start to see this problem in Sequoia. I saw it in Mavericks.

Clearly, this hasn't been a priority for Apple. But maybe if people start experiencing networking problems with Safari, the Apple Safari engineers will pressure the Apple networking engineers to fix their code.

Until then, don't try downloading to a network volume. It won't work.

To clarify further...

I'm running Ventura and everything was working fine with Safari downloading anywhere... until the latest Safari Version 18.0 (18619.1.26.111.10, 18619)

After that, download starts; file.download is created on my NAS drive; and then when all done, Safari says it couldn't move the file.

This is new and is happening to everyone I'd guess who happens to always or sometimes (as do I) choose a download location on a NAS -- I haven't tried just an external drive.

AND YES, I did set that the new Safari should have access to FULL DISK ACCESS in settings.

This is clearly a bug in the new Safari.

I'm Sequoia 15.1.1. same issues, downloads to a NAS drive won't finish.

Can't move file error.

they look like this:

Wonderful Imagination copy.wav.download

My fix.

Duplicate the downloaded file, then remove the ".download". from the end.

This workaround seems to work for me until Apple fixes it.

Just ran into this tonight downloading to NTFS (Paragon) external drive. On Ventura 13.7.1 (22H221), Safari 18.1.1 (18619.2.8.111.7, 18619). What I found is that Safari left a bunch of ".download" files. If you open a Terminal (CLI) and navigate to the appropriate directory, you should notice that those *.download files are actually directories, not files. Within the directories you should see the files you're looking for. I had downloaded some large DMG and ZIP, and used 7zip to verify those... so everything seems to be OK, even though Safari can't move the files after download.

1.) Open finder, navigate to the parent of the relevant download folder

2.) Right-click on the folder, select "New Terminal At Folder"

3.) type: ls *.download => you should see the files listed along with the directory names

4.) type: mv *.download/* . => this moves the contents of each *.download directory into the current directory

5.) Verify your files, as necessary for sanity (e.g., you can install 7zip via MacPorts or whatever)

6.) type: rmdir *.download => this will remove the empty directories... if not empty, this will fail

macmustache wrote:

1. > You’ll need to review what 3rd party system modifications you have installed. The most likely candidate is some kind of file-sync system.

I don't think that's likely at all:

It's certainly "likely". That doesn't necessarily mean it is the cause for each and every problem. There are only a handful of people reporting this problem. The problem is quite unusual. There are only a handful of possible causes. The burden is on you to investigate. All we can do is provide possible suggestions for places to look.

For example, one person mentioned downloading files to a network volume. That's obviously not going to work. Network support in macOS gets worse every year. This kind of temporary-download-then-move-into-place is an operation that is well-known to fail on a network volume. 3rd party browsers aren't going to do that, so they would be less likely to fail in this situation. So if you are using a network volume, don't do that.

Apple has no idea about how to manage this. Days ago I used AppleCare to try solve this and they began with not useful tests as reboot, reboot secure mode... So I left the support.

Safari can't save downloads to network share folders, does not matter if destination is a Mac or a SAMBA Linux share, always happens what this issue describes.

If you print to PDF from Safari, no problem it's saved in network share.

Other browsers (ie Firefox) or copying from Finder to share --> no problem.

They even told me to upgrade to Sequoia "to test".

Do anyone has a solution for this or knows an open Apple case about this?

I use Little Snitch and not going to remove it, as only Safari is having issues.

Thanks

Edit: This is happening me both in Ventura 13.7 and Sonoma 14.7, so not only a Sequoia thing.

Having the same issue, download folder is on a NAS. works fine if downloading straight to a mac. wish this was fixed since I work off my NAS

You are absolutely right. I have been using a NAS and store everything in the NAS from 2018. I download all the files directly to the NAS and I haven't had issues until this week that I installed macOS Sequoia in a new hard drive. I mean downloading from Safari. Firefox and Librewolf have no issues.

As you are saying, Safari downloads the file in a folder of the same name of the file it's downloading and I think I may have some clues and why is happening. Finder in macOS Ventura and also Monterey had quite a bug when renaming files in a network shared folder. Once moved or renamed, Finder was not able to find the file in a while (the time it took no-one knows). If you open the file from a Third party application chances were that you could open the file, even QuickLook would work but Finder was unable to open it, rename it or move it. So I think it's happening again, when in Safari you configure downloads to ask you or even if you set it up to download directly without asking to network because of Safari using Finder internally it creates a Folder with the actual file name, then it renames to .download so it can move the original downloaded file to the parent folder and delete the temp file, and because it's slow once renamed it does not find the renamed folder, so it cannot get inside and move the download original file.

I am going to paste my nsmb.conf I created manually after lot of research because I had a lot off issues when this bugs were happening with a Qnap NAS but not with a TrueNAS server.

Keep in mind that this is for trusted local area network environment where I am just myself.

Probably you should not disable packet signing nor session signing.

One of the biggest issue is Finder's Caching. (Path Finder and other third party managers work way better).

[default]

# Disable NetBIOS
port445=no_netbios

# Disable packet signing
signing_required=no

# Disable SMB session signing
#validate_neg_off=yes

# Enable SMB session signing
validate_neg_off=no

# Disable directory caching
dir_cache_max_cnt=0
dir_cache_max=0
dir_cache_off=yes

# Disable SMB notifications
notify_off=yes

# Lock negotiation to SMB2/3 only
# 7 == 0111  SMB 1/2/3 should be enabled
# 6 == 0110  SMB 2/3 should be enabled
# 4 == 0100  SMB 3 should be enabled
protocol_vers_map=6

# SMB Negotiation (normal, smb1_only, smb2_only, smb3_only)
smb_neg=smb3_only

# Use NTFS streams if supported
streams=yes

# Set hard or soft mount of shares
# Hard mount: a request is issued repeatedly until the request is satisfied.
# Soft mount: tried until completed, the retry limit is met or the timeout limit is met.
soft=yes

# Apple SMB extensions
# ReadDirAttr: This feature changes how macOS handles reads of file metadata stored in
# alternate data stream when listing the contents of large directories. Finder info,
# access rights, and resource fork size are returned more efficiently for the files
# in the directory.

# OsxCopyFile: With the SMB2 protocol, Microsoft implemented server-side optimizations
# when copying files between directories on the file share. The extension introduced by
# Apple ensures that all Apple-specific file metadata is properly copied along with the file
# itself. The copy process is also simplified as it is executed in just one request as
# opposed to splitting the requests into logical chunks which was the case in
# the original feature.
aapl_off=false

# File IDs are legacy compatibility elements for AFP and are not supported by SMB.
file_ids_off=yes

# Disable multi-channel connections and prioritize the wired ethernet connection
mc_prefer_wired=yes
mc_on=no

# Enable multi-channel
#mc_on=yes

But I still have not found a solution to the Safari download issue.

Safari 18.5 and the download issue persist, only downloading when you choose desktop.

very disappointing...