Error: "Invalid argument" when trying to add a network share as a media source

Help and Support
1

Hi,
I have a reletively decent HTPC run by windows 10, which has 4 internal and 4 external drives that contain media files. All the 8 drives are shared in my network under names equal to the drive letters given by windows, and I use the most basic file sharing method: smb1 with anonimous login to these drives. All the shares works flawlessly both on other windows machines and on my MacbookPro too, all in the same network, i.e. my HTPC acts as a pseudo NAS.

Two weeks ago I bought a used Vero 4K+ to play 3D or other movies for transmitting 3D contents on a Nvidia geforce 1050 has become very awkward ever since the company gave up supporting stereoscopic 3D.
I thought Vero 4K+ would just be perfect to this role and as it had become clear very soon it was indeed. Although it requires some timeconsuming forum reading to understand how it works, once you have done with it, you’ll get a precious little media device to use with some extra comfort that you may not have in your HTPC.

And now comes my problem.

A couple of days ago I had to reinstall windows on my HTPC. Everything went fine, except that two of the 8 drives did not get their previous letters from windows, which I had to repair and reassign manually. At the end of the win10 reinstall process onto my HTPC I gave all the necessary NTFS rights and NFS share permissions to all the drives and went through all the custom procedure to make smbv1 filesharing working in my network. All the windows pc-s and laptops and my MacbookPro could see all the 8 network shares from my HTPC.

Unfortunately that is not the case with my Vero 4K+, for only 6 out of the 8 network drives can be connected. If I try to connect drives which were mistakenly lettered right after the windows reinstall, I allways get the error message: “Invalid argument”, no matter what I do.
Here is what I have made so far to avoid loosing the possibility of two of my prescious network drives on Vero 4K+.

1/ In windows of my HTPC

  • took ownership of the drives and give it back to the usergroup which are owners of the other drives
  • diabled sharing and then resharing, providing the necessary permissions for the shares
  • rename those drives and there share names
  • cleaned up and erased corrupted recycle bins, even deleted temporarily the System Colume Information folders of those drives

2 In my Vero 4K+

  • managed to do a clean install then successfully went through update processes pendig
  • made all the necessary Kodi settings for using network shares

Yet the error message remains and only 6 out of my 8 win shares can be connected as a media source to my Vero 4K+.

Can you help me on this please? At least giving me advice where should I look for solution?

2

Are you sharing via SMB or NFS or both?

3

I do not know how to use NFS in my case, so I just use SMB.

4

Then I assume it was a typo above.

Upload your logs via MyOSMC so that we can help.
You might also want to check if you have old credentials in .kodi/userdata/passwords.xml

5

As soon as I got home, I"ll do it.

6

Why? Win 10 now goes out of its way to disable both SMBv1 and guest networking. Would it really be that big of a deal to just make a second user account with a password and give permissions to that user for your media shares?

Regardless, this sounds more like a Windows issue. Right click on a drive/folder (IMO you should be sharing a folder and not an entire drive) that is not showing up and select properties. Under sharing>advanced sharing>permissions> make sure that there is at least read permissions for “guest” and/or “everyone”. If your drive is formatted NTFS then back out of the previous screen and click on the Security tab of the properties window and then click advanced and then effective access. Click on select user and in the object box type in “guest”, hit enter, and then click on view effective access. This will show if you have read access at the file level.

7

As long as I can see, there are no old credentials in that directory. I have just tried to upload my logs, I’ll check if it is available to others from https://paste.osmc.tv/epikawakun.

8

Hi Darwin,
for the time being in our local environment SMB v1 without passwd is an absolute easy way to share media files, especially it also works on my Mac.
I do not think this error is a windows issue, for the drives are easily accessible from other PC-s or laptops in out network. Even Kodi running on a windows PC can find and use them. I have already given all the NTFS rights and share permissions, these type of settins are the same on every drive, including those that are accessible to my Vero.

All I can imagine: once reinstalled, windows left something confusing into the system files of these drives, that are ignored for Mac or for other win PC-s but for some reason they bother Vero 4K.
Another possibiliy: unfortunately I forgot to shut down my Vero 4K+ during the above windows reinstall. Being online all the time of that procedure Vero somehow got confused when the two drives got different letters for a little bit of time and somehow this “confusion” can not be undone. Even though I succeeded to conclude a clean install this morning, the problem remained.

9

And your sure your other PC’s are using a guest user and SMBv1 to access the file shares like your forcing the Vero to? If the Vero (SAMBA) can access 6 of the 8 file shares you say you have setup in the exact same manor and using just a single letter as a share name then how exactly do you think one share is being seen different from another in Kodi? You say you did a clean install of the Vero so there can be no issues with old credentials in Kodi’s database or passwords.xml. It looks to me like Kodi is just asking for a straight UNC file path and Windows is saying it is not available. This would lead me to believe that it is a Windows side issue. Are the two drives not showing up using a different file format than the others?

As for the Windows reinstall screwing something up, this would be file permissions of a NTFS formatted drive. The share settings are not stored on the drives themselves so a clean OS install would leave nothing behind as far as the actual folder sharing goes. However file and folder permissions of a NTFS formatted drive tied to user accounts from the old reinstall will show up as weird string. In this case you may have to do some playing around with applying permissions and/or disabling inheritances to get access back to these files/folders. Thus why I said to check effective permission of the guest account for those drives.

10

Here are the relevant lines from the log:
GetDirectory - Error getting smb://NAPPALI/I/
2021-11-16 20:54:11.659 T:2575
ERROR : CGUIDialogFileBrowser::GetDirectory(smb://NAPPALI/I/) failed

11

What part of that log contradicts what I posted? If you don’t have file permissions for the guest account to browse that folder then you will get a failure like that. Perhaps you could try…

smb://username:password@NAPPALI/

using the credentials from an account on that PC and see if it pops up with the “I” share then.

12

Right you are! That log is a confimation of your concept about the nature of the problem which has nothing to with Kodi or OSMC. It is something that windows messed up somewhere around the UID/GUID NFS mapping of those two drives. Issue of ownership, NFS rights and SMB share permissions … meaning you were right on the possible methods to fix it, too.
Unfortunately no luck so far, but now I’ll give your last suggestion a try.
Thanks for your precious time bothering with my issue .

1 Like
13

In your logs I don’t see any sources defined, so I assume the SMB entries are coming from your existing library?
May I suggest to you to connect to the Vero via SSH and check the following:

sudo apt-get install smbclient
smbclient -L 192.168.1.64

and share the output of the second command.

16

Just a FYI. NFS (network file system) is a networking protocol primarily used in Linux. NTFS (New Technology File System) is a drive format primarily used in Windows. It is a bit confusing when the wrong acronym is used.

18

I was able to connect to NAPPALI with the method you suggested, but had no luck with drive “I”.

19

You are right again, it supposed to be ‘NTSF rights’.
(My mistake, for it is not that wise to write comments to here when you are in a hurry to your work)

20

It’s correct there are no media sources on my Vero 4K+ for the time being. The reason is: once I executed a clean install yesterday, I decided not to set up media sources to the above unit untill I found solution to my problem raised in this ticket. Mind you I still have my HTPC to run those media files, so I just wanted to have my Vero 4K+ empty.
Here are the results of my ssh findings:
“root@osmc:~# sudo apt-get smbclient
E: Invalid operation smbclient
root@osmc:~# smbclient -L 192.168.1.64
-bash: smbclient: command not found”

21

Sorry my mistake, forgot install command (corrected my post now.
Please execute again.
sudo apt-get install smbclient

22

Once “install smbclient” finished successfully, the second command gave me the following output using ‘root’ as a user:
"root@osmc:~# smbclient -L 192.168.1.64
Enter WORKGROUP\root’s password:

Sharename       Type      Comment
---------       ----      -------
ADMIN$          Disk      Remote Admin
C$              Disk      Default share
D               Disk      
D$              Disk      Default share
E               Disk      
E$              Disk      Default share
F               Disk      
F$              Disk      Default share
G               Disk      
G$              Disk      Default share
H               Disk      
H$              Disk      Default share
I               Disk      
I$              Disk      Default share
IPC$            IPC       Remote IPC
J               Disk      
J$              Disk      Default share
K               Disk      
K$              Disk      Default share
L               Disk      
L$              Disk      Default share
Users           Disk

Reconnecting with SMB1 for workgroup listing.
do_connect: Connection to 192.168.1.64 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
Failed to connect with SMB1 – no workgroup available
root@osmc:~# "

Only two of the above shares are impossible to use from VERO 4K+:
‘I’ and ‘K’, the rest works like a charm.
From anywhere else within ‘WORKGROUP’ ‘I’ and ‘K’ can be accessed without any problem.

23

So what happens when you compare:
smbclient -N //192.168.1.64/F/
with
smbclient -N //192.168.1.64/I/