Skip "Verifying [file name]" in High Sierra?

Solution: https://forums.macrumors.com/threads/osx-10-12-4-beta-verifying-dialog-on-openin g-any-movie-zip-files.2030204/

This has existed since January, noone at Apple cares. Solution above worked for me.

Command:

xattr -d com.apple.quarantine "foobar.mp4"

Then open file

Same problem. Dragging/dropping onto VLC dock icon still brought up the 'Verifying...' box. Instead went into VLC and did a file/open file..., navigated to the video file I wanted and voilà, it opens.

This seems to be happening to a lot of people. There are a few threads regarding this issue. Hoping they are somehow going to fix this. Playing videos it happens on both VLC and Quicktime. Also good luck if extracting a large file you will get the same message. I had a 100GB file I was trying to extract using ZIPEG and after 45 minutes I went to lunch. Not sure how long it actually took to verify.

The steps they had me take to try to fix it did not work. So if they tell you to try what is in my thread I wouldn't bother.

verifying progress bar on every file.

Found solution! 🙂

Noticed the same thing with my Macbook Air but not my Macbook Pro. After reading this discussion thread, it got me looking at my settings in Preferences under Security & Privacy. Under the Allow Apps Downloaded from section, the checkbox was for App Store and Identified Developers for my Macbook Air but not my Macbook Pro. Changing it to Allow Apps downloaded from App Store fixed the problem for me.

This is likely a bug in High Sierra but this is the workaround that I discovered. Seems safer than that other solution earlier in this thread.

Same here. Macbook pro retina 2015 recently updated to High Sierra 10.13. Takes ages to verify each video file imported from my Gopro. Every single time i want to open a video i have to wait 3 mins for it to verify! Please fix this.

My iMac is Mid 2011 High Sierra. Have the same problem for all types of videos playback. Among all the video the MKVs are the worst since they are all biggest video files on my SSD. However, my MacBook Pro, mid 2010 Sierra, never had a problem like this, glad that I didn't update my MBP in hurry.

I installed a update today Oct 6th but the problem still exists. Guess Apple didn't find a solution?

It's a bug in Quicktime. On every opening it adds the xattr (extended attribute) com.apple.quarantine on every file opening. I hope Apple will fix this on a next update soon. The only workaround I know is to remove that xattr on every file (on network delete all ._* files where the xattr are saved on Samba shares) and try not to open the video file with Quicktime and use an alternative.

Happens to everybody except Apple testers because they don't have large enough files to notice the message.

How large of a file do I need?

6GB over an SMB connection to a spinning hard drive didn't produce any dialog at all.

This worked for me.

Try this:

open up terminal.app and run this:

defaults write com.apple.LaunchServices LSQuarantine -bool NO

Please Note: Restart is required to make it work.

OSX 10.12.4 Beta - Verifying dialog on opening any movie/zip files? | MacRumors Forums

...you are a SAINT. This has been driving me around the bend as well and I've just tried your fix and it works instantly.

Now all we can do is hope they will restore Ringtones in iTunes...many thanks for this workaround! 🙂

I can't prove that this will work in all cases, and on anything else apart from either Quicktime Player 7 or 10, but i just found that if I quit that annoying 'verifying' notification as soon as it opens (by hitting the 'x' on the right-hand end), and reopen the video (.mp4), then the verification no longer happens for that particular video. Could be a simple workaround until Apple fix the bug?

(On my 2010 MacBook Pro, verification doesn't seem to happen with .mov files or even .mp3s)

I think I have found a solution.

When I "get info" on a video file it shows read/write set for me, but read only set for Admin. If I set the file to read/write for Admin it opens and plays without delay or dialog.

I set the read/write for Admin for the enclosing folder of the videos and now they preview with the spacebar just fine, but to double click open them with other apps (VLC etc) the files need to be more or less individually set. I tried selecting 30 files and pressing "command option i" and I was able to set them all to Admin read/write in one shot, but when I tried it with a few hundred it did not show the option to change read/write. I am sure it is a trivial task to recursively do that for all files and folders with some terminal fu that I do not possess.

Exact same problem here, every time I want to see a .mp4 o .mkv the Verifying popup show up.

I am using an iMac 27" Late 2012 with Fusion Drive.

The only "solution" that I found, is to open first the VLC and them do Drag and Drop, in this case, the Verifying popup dosen't appear and the file start to reproduce directly.

Here is the solution: if you have Avira installed in your Mac, uninstall it and see if the problem got fixed. If not, then the problem can be fixed through clean re-install the Mac OS latest version. And don't install Avira for Mac until it fixes the bug. (Avira is working fine with 10.13.1, but not 10.13.2)

I had the same problem after I upgrade by system from 10.13.1 to 10.13.2, and I tried all the methods recommended by other people, but those solutions just won't work for me. So I did a clean re-install my system, and the problem was fixed until I install the latest Avira to my Mac... There must be some kind of bugs that Avira has on 10.13.2. Once I uninstall the Avira, the problem just goes away.

To find this problem it took me 2 days, and I clean re-install the Mac OS 3 times to check at when and how the problem showed up....Hope my method will fix your problem as well.

I am having this problem with ALL files, seriously slowing my iMac with 24GB of Ram - so it's not the system it's the bug. Any idea when Apple is going to fix this? I have clients that are basically freezing because of this Verify problem as well.