Exiftool gets blocked from accessing files over the network

Started by Lukas52, September 14, 2021, 04:19:24 AM

Previous topic - Next topic

Lukas52

Hey,

Since the latest update Microsoft forced down my throat, 20H2 in my case, exiftool can't access files on network shares anymore. At first i thought it was an issue with the DAM i use (iMatch 2021), which does use exiftool for all of its Metadata reading and writing. So i tried using the supplied Version of exiftool via command line, but that still doesn't work.

C:\Program Files\photools.com\imatch6> .\exiftool \\NOARA\Test\Test\Test.jpg
Error: File not found - //NOARA/Test/Test/Test.jpg


I tried mounting the Share as a Network drive but that behaves exactly the same. I then tried Oliver Betz Modified Version, but that returns the same issues.
Local files work just fine, both reading and writing.

IMatch writes this into its logs:
ETWARN:File '\\NOARA\Vault\Test.jpg' does not exist for -tagsFromFile option
File '\\NOARA\Vault\Test.jpg' does not exist for -tagsFromFile option


So it looks like exiftool simply isn't seeing the Networked Files.
I definitly have access to these files tho. I can move/rename/delete/create them just fine, and so can IMatch, it's just everything involving exiftool that doesn't work.

The IMatch developer told me this seems to be an issue with Windows Security, however i have tried turning of everything i can under the "Update & Security" tab, restarted my Computer, made sure everything is still turned of, and than tried again with the same result.
IMatch exiftool Version is 12.29
Oliver Betz exiftool Version is 12.30

I honestly don't know what else to try. My Shares are all SMB v3, with both read and write privileges set. The SMB log does show that at least on every first try after a system reboot it does create a [FILENAME].jpg_exiftool_tmp, however they are always 0KB in size, however if i'm trying to write Metadata to files that don't support it, like a txt file, it does create a *.xmp_exiftool_tmp and a .xmp file that does contain all the Metadata. It still errors out during readback tho. (File not found again).

StarGeek

That is very weird.  I had to double check my Windows version

and I have no problems accessing my media server using both direct share path or as a mapped drive.

I did some google searches and couldn't find a result where the share was accessible normally, but not by certain programs.  I searched specifically on Perl for that.  It was either all access or no access.
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

Phil Harvey

What shell are you using?  cmd?

Do the "dir" and "type" commands work?:

dir \\NOARA\Test\Test\Test.jpg

type \\NOARA\Test\Test\Test.jpg

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

auanasgheps

Hi, apologies for this necro reply, but I am facing this exact issue.

Windows 10 22H2.
Exiftool 12.81
SMB Share from my NAS mounted as Z:\
Exiftool works perfectly with local files, but unable to see those on the share.
Powershell is run as user, not administrator (who would not see the share, and in fact the dir command would not show any Z:\ drive).



PS C:\Users\Oliver> exiftool -ee "Z:\Test\HD FH 15.3.mp4"
Error: File not found - Z:/Test/HD FH 15.3.mp4
PS C:\Users\Oliver> dir 'Z:\Test\HD FH 15.3.mp4'


    Directory: Z:\Test


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
------        12/04/2024     19:57         885975 HD FH 15.3.mp4

StarGeek

Have you tried accessing it as share rather than mounted network drive, i.e. \\<NameOfShare>\path\to\file.mp4? Also try CMD instead of PowerShell.  And make sure there aren't any more complex characters in the file path, such as accented or umlaut characters.

But this most likely isn't an exiftool problem as I regularly access files on my Unraid server by both share \\Tower and mounted drive share U:\.
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

Phil Harvey

...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

auanasgheps

Something weird is going on: I can access other files on the same Z:\ but in other folder(s).

If I use cmd, I get the same behavior.

I'm trying to understand but I can't get anywhere.

EDIT: Tried making changes to file permissions, Linux side, they do not have an effect. Using CMD or Powershell I can see those files. It's exiftool that is unable to find some of those in a specific path.

auanasgheps

The problem is within the files, not folders.

I'll explain my scenario:

I built a Powershell script that converts video files using Handbrake and then copies Date information using exiftool.

Exiftool is unable to read the files that my script creates if are on a mounted share. If in the same folder I copy a photo or video I already own, Exiftool can read it successfully.

But my workflow works perfectly when used on a local disk. Tomorrow I'll do more tests.

StarGeek

Quote from: auanasgheps on April 13, 2024, 11:54:54 AMI built a Powershell script that converts video files using Handbrake and then copies Date information using exiftool.

Make sure and test in CMD first.  Powershell breaks on many basic exiftool commands because its quoting rules are different from CMD/Mac/Linux. See this post.  In the image, the top command works in CMD. The bottom command works in Mac/Linux.  Neither of them work in Powershell.
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

StarGeek

This is a stretch, but try running this command on the NAS (not a Windows command) and copy/paste the results here

sudo smbstatus

Here's what I get. I cut the "Locked Files" section because it probably won't help, but look it over on your output to see if there's something interesting
root@Tower:~# sudo smbstatus

Samba version 4.17.10
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing             
----------------------------------------------------------------------------------------------------------------------------------------
25517   nobody       users        192.168.1.5 (ipv4:192.168.1.5:49400)      SMB3_11           -                    -                   

Service      pid     Machine       Connected at                     Encryption   Signing    
---------------------------------------------------------------------------------------------
Movies_And_Television 25517   192.168.1.5   Sat Apr 13 06:22:33 AM 2024 PDT  -            - 
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

auanasgheps

I have already battled a fair number of Powershell issues with Exiftool, and I think this is not another of those.
I'm not a coder and I know Powershell much better than CMD what's why I use it.


Here's another test:
- edit my script so it only does the handbrake conversion, exiftool is not involved.
- run the script to convert a test video
- browse to the destination folder and execute 'exiftool -ee <filename>'. Both Powershell and CMD are failing. I tried both drag-n-drop and autocomplete by typing the first filename letter.

PS Z:\Testarello> exiftool -ee '.\HD FH 15.3.mp4'
Error: File not found - ./HD FH 15.3.mp4
PS Z:\Testarello> cmd
Microsoft Windows [Versione 10.0.19045.4291]
(c) Microsoft Corporation. Tutti i diritti sono riservati.

Z:\Testarello>exiftool -ee "HD FH 15.3.mp4"
Error: File not found - HD FH 15.3.mp4

Z:\Testarello>dir
 Il volume nell'unità Z è media
 Numero di serie del volume: 1004-1E83

 Directory di Z:\Testarello

12/04/2024  19:57    <DIR>          .
13/04/2024  17:24    <DIR>          ..
14/04/2024  12:44           885.975 HD FH 15.3.mp4
14/04/2024  12:44           767.967 HD FX 16.5.mp4
14/04/2024  12:44           292.112 HD HQ 11.3.mp4
14/04/2024  12:44           371.595 HD LP 5.mp4
14/04/2024  12:44        12.849.238 YDXJ0197.MP4
               5 File     15.166.887 byte
               2 Directory  11.207.030.398.976 byte disponibili

Z:\Testarello>exit
PS Z:\Testarello> dir


    Directory: Z:\Testarello


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
------        14/04/2024     12:44         885975 HD FH 15.3.mp4
-a----        14/04/2024     12:44         767967 HD FX 16.5.mp4
-a----        14/04/2024     12:44         292112 HD HQ 11.3.mp4
-a----        14/04/2024     12:44         371595 HD LP 5.mp4
-a----        14/04/2024     12:44       12849238 YDXJ0197.MP4


So I think Powershell is not the culprit.


So I ran smbstatus on my NAS (Debian 11 / OpenMediaVault) and I don't see anything weird. The test folder is locked, but when I close File Exporer on my PC is not locked anymore.


root@nas:~# smbstatus

Samba version 4.13.13-Debian
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
----------------------------------------------------------------------------------------------------------------------------------------
14387   oliver       users        192.168.0.100 (ipv4:192.168.0.100:64752)  SMB3_11           -                    partial(AES-128-CMAC)

Service      pid     Machine       Connected at                     Encryption   Signing
---------------------------------------------------------------------------------------------
data         14387   192.168.0.100 Sun Apr 14 11:40:07 2024 CEST    -            -
media        14387   192.168.0.100 Sun Apr 14 11:40:07 2024 CEST    -            -

Locked files:
Pid          User(ID)   DenyMode   Access      R/W        Oplock           SharePath   Name   Time
--------------------------------------------------------------------------------------------------
14387        1000       DENY_NONE  0x100081    RDONLY     NONE             /srv/dev-disk-by-uuid-b80b861a-7de2-4733-a1c8-07cd3d836474/storage/media   Testarello   Sun Apr 14 12:48:22 2024

As I said, Exiftool can read other files on the share. I compared the files on the NAS file system, and the converted files have even more rights (but this does not apply, i am the oliver user)


Exiftool can read:
root@nas:/srv/hdd/media/Foto e Video/Test/Originali# ls -ll
total 479328
-rw-rw---- 1 oliver users   5505024 Jul 24  2023 00031.mts
-rw-rw---- 1 oliver users 295993344 Jul 24  2023 00032.mts
-rw-rw---- 1 oliver users  47382528 Jul 24  2023 00033.mts
-rw-rw---- 1 oliver users  30179328 Jul 24  2023 00034.mts
-rw-rw---- 1 oliver users 111771648 Jul 24  2023 00035.mts

Exiftool can't read:
root@nas:/srv/hdd/media/Testarello# ls -ll
total 14824
-rw-rwx--x 1 oliver users   885975 Apr 14 12:44 'HD FH 15.3.mp4'
-rwxrwx--x 1 oliver users   767967 Apr 14 12:44 'HD FX 16.5.mp4'
-rwxrwx--x 1 oliver users   292112 Apr 14 12:44 'HD HQ 11.3.mp4'
-rwxrwx--x 1 oliver users   371595 Apr 14 12:44 'HD LP 5.mp4'
-rwxrwx--x 1 oliver users 12849238 Apr 14 12:44  YDXJ0197.MP4
root@nas:/srv/hdd/media/Testarello#


I want to underline that my script works perfectly when used with local folders, even if they have spaces. I spent a lot of time to ensure they were parsed correctly.


So I kept testing, and discovered that: a converted file from the share that exitool can't read, if is copied on my PC then copied again in the original folder share, overriding the file, now exiftool can read it.

The problem for exiftool is how handbrake outputs these files on the share, but does not make any sense because I can't find a difference with other files that work perfectly.



obetz

You might try to let exiftool find the filenames itself, e.g. "exiftool -ee ."

Is there a reason why the date format in the "can read" ls output ("Jul 24  2023)" differs from the "can't read" listing ("Apr 14 12:44")?



StarGeek

Quote from: obetz on April 14, 2024, 09:09:36 AMIs there a reason why the date format in the "can read" ls output ("Jul 24  2023)" differs from the "can't read" listing ("Apr 14 12:44")?

I think that's just how the linux ls command works with the long list -l option, at least according to my quick Google search.  I use a Windows port of linux commands and using ls -l will output the time if the file has a time stamp for this year, or it will give the year if it's not the current year.  For example
-rw-r--r-- 1 bkw-M bkw-M         0 Apr 24  2018  temp9.txt
-rw-r--r-- 1 bkw-M bkw-M         0 Mar 20 11:05  temp_Error.txt

(I really need to delete some of these temp#.txt files :D)

But otherwise, I got nothing.  The fact that some other files on the share will work and that when you copy from the directory and then back makes it work has me stumped.
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

stoffball

Quote from: auanasgheps on April 14, 2024, 07:21:24 AMExiftool can't read:
root@nas:/srv/hdd/media/Testarello# ls -ll
total 14824
-rw-rwx--x 1 oliver users  885975 Apr 14 12:44 'HD FH 15.3.mp4'
-rwxrwx--x 1 oliver users  767967 Apr 14 12:44 'HD FX 16.5.mp4'
-rwxrwx--x 1 oliver users  292112 Apr 14 12:44 'HD HQ 11.3.mp4'
-rwxrwx--x 1 oliver users  371595 Apr 14 12:44 'HD LP 5.mp4'
-rwxrwx--x 1 oliver users 12849238 Apr 14 12:44  YDXJ0197.MP4
root@nas:/srv/hdd/media/Testarello#


For these files the execute flag is set. For the working files it is not set.
This should not be set for mp4 files?

obetz

thanks for the clarification about ls.

My suggestion is intended to exclude a Linux - Windows filename strangeness