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).
That is very weird. I had to double check my Windows version
(https://i.imgur.com/sYARliH.png)
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.
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
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
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:\.
Also maybe check the file permissions?
- Phil
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.
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.
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 (https://exiftool.org/forum/index.php?topic=14962.msg80581#msg80581). In the image, the top command works in CMD. The bottom command works in Mac/Linux. Neither of them work in Powershell.
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 - -
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.
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")?
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.
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?
thanks for the clarification about ls.
My suggestion is intended to exclude a Linux - Windows filename strangeness