Directory /media/autofs/dir does not exist.

[engjs]

I have a directory G:\DIR on a USB drive plugged into my PC (Windows 10 Pro), shared as \\MYPC\DIR. I have shared this directory to my home network, and can read it from another PC on the network.

I go to menu > Setup > Network > Network Browser, scroll down to 192.168.1.2 ( MYPC ), press OK to see the shares, move to DIR and press OK. I change Local share name "DIRMYPC" to "DIR" and Mount options "rw,utf8" to "ro,utf8". The rest default correctly. The beyonwiz mounts the share, tells me it is mounted, and shows me a green icon. I save and exit the menus.

I press Media, browse to the /media/autofs directory, and the DIR directory is present. I click on it and get the error message: Directory '/media/autofs/DIR' does not exist.

From the T4 root account I see that /media/autofs/DIR exists (dr-xr-xr-x 2 root root 0 Jul 27 22:48 DIR) but when I cd to it I get "cd: can't cd to DIR/".

It looks to me as if there is something wrong with the mounting process by I can't fiugure out what. How do I fix this? Thanks in advance for your help.

Jim

[MrQuade]

It looks to me as if there is something wrong with the mounting process by I can't fiugure out what. How do I fix this? Thanks in advance for your help.

Earlier versions of the Beyonwiz firmware default so using SMB version 1 which is no longer compatible with Windows 10 security settings.

Make sure you are using a user name and password to access the share for starters.

Secondly, make sure that you add "vers=2.1" to the mount options to make the Wiz use SMB version 2.1 to access the Windows PC.

[engjs]

The mount point has username and password set, and they're correct. That said, I've turn off the password protected sharing setting on the PC in order to get the Network browser to work.

I changed the mount options to "ro,utf8,vers=2.1" and cycled the T4. It didn't fix the problem.

Under menu > Information I found:

Drivers: 2016-04-05
Image: 16.1
Kernel: 3.14.2
Last Upgrade: 2017-03-10 04:30

Until recently I had a WD Mybook Duo Live drive shared to the T4 and it worked fine.

[MrQuade]

You should consider updating to the 17.5 series firmware which contains a lot of enhancements to the networking to deal with the latest security measures.

Going from 16.1 to 17.5 does mean you will need to re-enter your settings and timers from scratch though.

Until recently I had a WD Mybook Duo Live drive shared to the T4 and it worked fine.

Yes, it likely allows low security SMB connections to be made whereas Windows no longer does.

The mount point has username and password set, and they're correct. That said, I've turn off the password protected sharing setting on the PC in order to get the Network browser to work.

I don't think it is sufficient to just turn off password protection on Windows any more since the last security updates.
You can go into the Windows features and turn SMB 1 back on, but I don't recommend it. You should instead make sure the Wiz can connect at the recommended level of security.

[prl]

Going from 16.1 to 17.5 does mean you will need to re-enter your settings and timers from scratch though.

And if you don't, you'll never get any firmware updates. Actually, you'll never get any updates to the 17.5 series, either, but at least it's more recent, and you don't need to re-do settings to go to the current 19.3 firmware series.

Bugs in the 16.1 firmware series simply won't get fixed unless they're also in current firmware, but then that'll only get fixed in the current firmware.

[engjs]

I've upgraded to 17.5 firmware, set it all up again, set up the mount point again, it still gives me the same error message.

[Paul_oz53]

I've upgraded to 17.5 firmware, set it all up again, set up the mount point again, it still gives me the same error message.

How do you allocate IP addresses?

I used to have a lot of problems with the Master Browser failing to find shares but since adopting router assigned to MAC addresses problems are rare and usually are down to the credentials.

[engjs]

How do you allocate IP addresses?

I don't use DHCP. Each device in the subnet gets its own IP V4 address, which I type in manually. That way if I see an IP address I know which device it links to.

What puzzles me is that the T4 seems to be going through the process of mounting the share without thowing any errors. It's only when you try to access the share, either through the Media Player or via unix that the error is thrown. I'd like to look through the automount logfile, but I don't know where it is, and in any case I've a feeling that there wouldn't be anthing abnormal there.

[MrQuade]

I've upgraded to 17.5 firmware, set it all up again, set up the mount point again, it still gives me the same error message.

Are you providing a valid username and password in the mountpoint configuration to access that share?

I don't use DHCP. Each device in the subnet gets its own IP V4 address, which I type in manually. That way if I see an IP address I know which device it links to.

That answers Paul_oz53's question.
Static assignment of addresses should work the way you are doing them.

A better way to set them up is to define all of the static addresses in your router's DHCP configuration. You still have fixed IP addresses, but they get assigned automatically by MAC address. This way, each device's DNS host name is automatically registered in the router's DNS server, which makes certain network operations a lot easier.
Admittedly it is a pain to assign address by MAC if you have a lot of devices, and not all routers have the functionality to do so (though most decent ones will).

[Grumpy_Geoff]

What puzzles me is that the T4 seems to be going through the process of mounting the share without thowing any errors. It's only when you try to access the share, either through the Media Player or via unix that the error is thrown. I'd like to look through the automount logfile, but I don't know where it is, and in any case I've a feeling that there wouldn't be anthing abnormal there.

I think time for the "show" part of "show & tell" as the "tell" part has it not working.
Clearly you can telnet and use the command line, so get onto the box and via 'cat', FTP, or using File Commander, grab the contents of these -
/etc/enigma2/automounts.xml
/etc/auto.network

Mask the user and password.

[Paul_oz53]

Definitely post the files as Grumpy_Geoff suggests. A mismatch between them can cause problems like yours.

As MrQuade infers, having the exact user_id & password is also critical.

Like you, I used to manually allocate IPs and they worked most of the time but occasionally one would play up. The router assigned IPs linked to MAC address are superior. You could just try the T4 if nothing else works.

[Grumpy_Geoff]

Definitely post the files as Grumpy_Geoff suggests. A mismatch between them can cause problems like yours.

Yep, as far as I know, the mount is done from the contents of auto.network, so if that's wrong then you're looking at the wrong page from the map book (GUI view of automounts.xml) and hence travelling up shit creek instead of the network share-path super highway.

[engjs]

Like you, I used to manually allocate IPs and they worked most of the time but occasionally one would play up. The router assigned IPs linked to MAC address are superior. You could just try the T4 if nothing else works.

I know the IP's are working because I can telnet from the PC to the T4 using the IP address, and I can ping the PC from the T4 using the IP address of the PC.

Are you providing a valid username and password in the mountpoint configuration to access that share?

Yes, it's the account I log into the PC with, and it has administrator privileges.

I think time for the "show" part of "show & tell" as the "tell" part has it not working.
Clearly you can telnet and use the command line, so get onto the box and via 'cat', FTP, or using File Commander, grab the contents of these -
/etc/enigma2/automounts.xml
/etc/auto.network

Mask the user and password.

root@beyonwizt4:/etc/enigma2# cat automounts.xml
<?xml version="1.0" ?>
<mountmanager>
<autofs>
<cifs>
<mount>
<active>True</active>
<hdd_replacement>False</hdd_replacement>
<ip>192.168.1.8</ip>
<sharename>HYRULE</sharename>
<sharedir>HYRULE</sharedir>
<options>ro,utf8,Vers=2.1</options>
<username>username</username>
<password>password</password>
</mount>
</cifs>
</autofs>
</mountmanager>
root@beyonwizt4:/etc/enigma2#

root@beyonwizt4:/etc# cat /etc/auto.network
# automounter configuration
HYRULE -fstype=cifs,user=username,pass=password,ro,iocharset=utf8,Vers=2.1,cache=loose ://192.168.1.8/HYRULE
root@beyonwizt4:/etc#

[MrQuade]

Try vers=2.1 instead of Vers=2.1

I'm not entirely sure is the mount options are case insensitive or not.

[engjs]

Try vers=2.1 instead of Vers=2.1

I'm not entirely sure is the mount options are case insensitive or not.

Doesn't work either way. I has checked that previously.

[Grumpy_Geoff]

Do you have another computer you can use to access the HYRULE share from?
i.e from Windows command prompt -

Code: Select all

net use \\192.168.1.8\HYRULE * /U:{username}
[reply with {password} matching {username}]
start \\192.168.1.8\HYRULE

[engjs]

Do you have another computer you can use to access the HYRULE share from?

I have the share mounted and accessible from my wife's PC. Had a struggle to make it work; I ended up having to create a registry key on my PC to make it work.

It has to be "vers=2.1" not "Vers=2.1". The latter throws an error.

I've been checking /var/log/messages and I see the following.

When I save the mount point and tell it to recreate the mount from the menu system it throws: Jul 31 23:10:20 beyonwizt4 daemon.crit automount[24282]: rmdir_path: lstat of /media/autofs/.e2settings.pkl failed

When I try to access the mount it throws the following: Jul 31 23:12:29 beyonwizt4 daemon.crit automount[25755]: key ".e2settings.pkl" not found in map source(s).

There is no .e2settings.pkl entry in /media/autofs.

[MrQuade]

I have the share mounted and accessible from my wife's PC. Had a struggle to make it work; I ended up having to create a registry key on my PC to make it work.

Can you share what that key was?
The fact that you had trouble mounting from another Windows machine rings alarm bells that something is not set up right on your PC.

Have you checked to make sure your PC is in the "Private" profile and not the "Public" one? This can sometimes change for no apparent reason, and many sharing features are (rightly) disabled in the Public profile.

[Grumpy_Geoff]

The fact that you had trouble mounting from another Windows machine rings alarm bells that something is not set up right on your PC.

+1

[engjs]

Can you share what that key was?

I had to change HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\IRPStackSize to REG_DWORD 0x20 (32). I think it defaults to 15. It wasn't there so I created it. Without it attempts to access the share failed with an out of memory error. I assume it's because HYRULE is on a 4 terrabyte drive.

Have you checked to make sure your PC is in the "Private" profile and not the "Public" one?

Network and Sharing Centre says it is Private.

[Grumpy_Geoff]

Create a share on your wife's PC and see if you can access it from both the Wiz and your PC.

[engjs]

Create a share on your wife's PC and see if you can access it from both the Wiz and your PC.

I created a share. No errors. I mapped it on my PC and could access it. No errors. I set up a mountpoint for it on the T4. No errors. I tried to access the directory from the T4. "Directory '/media/autofs/DirComputer' does not exist." I checked the mountpoint setup and added ",vers=2.1" to the mount options, updated the share and then it worked when I accessed it.

I deleted the mountpoint for the share on my PC, rebooted the T4, and then created it again using exactly the same setup as for the share on my wife's PC. It still threw the error when I tried to access it.

The network browser will browse my wife's shares but will not browse mine. It looks like it is expanding the share list but not finding any shares to show. I can get it to browse mine by turning off password protected sharing, but doing so doesn't fix the problem with accessing the share.

I noticed that my wife's PC's network was Public. I switched it to Private. That made no difference to anything.

[MrQuade]

I created a share. No errors. I mapped it on my PC and could access it. No errors. I set up a mountpoint for it on the T4. No errors. I tried to access the directory from the T4. "Directory '/media/autofs/DirComputer' does not exist." I checked the mountpoint setup and added ",vers=2.1" to the mount options, updated the share and then it worked when I accessed it.

Excellent, that seems to be working as expected then .

I deleted the mountpoint for the share on my PC, rebooted the T4, and then created it again using exactly the same setup as for the share on my wife's PC. It still threw the error when I tried to access it.

So there is some difference here in the way your PC is configured it seems. Unfortunately Windows can get really hard to track down problems like this once things stop "just working".

The network browser will browse my wife's shares but will not browse mine. It looks like it is expanding the share list but not finding any shares to show. I can get it to browse mine by turning off password protected sharing, but doing so doesn't fix the problem with accessing the share.

Recent versions of Windows require the remote computer to first authenticate with the Windows PC, before the Windows PC will even list its shares. It used to be that you could allow anonymous listing of shares and anonymous access to the share contents, but this isn't the case unless "password protected sharing" is switched off. I'm not entirely sure what the effect of turning off password protected sharing is now that SMB1 is disabled by default on Windows 10 though (all the old workarounds are turning into a mess).

When you are browsing your PC from the T4, I presume that you are entering the username and password when you first click on the PC's name? That's the authentication step that is required before the PC will list any shares.

The fact that when you turn off password protected sharing, which disables that first check, allows you to see the share, but then not access the share contents suggests that the T4 is still having trouble properly authenticating as the user that has been given the share access permission.

Perhaps the Windows Event Logs will shed some light on this?

Are you able to temporarily disable any firewalls or security software you have installed that may be interfering with this process?

I noticed that my wife's PC's network was Public. I switched it to Private. That made no difference to anything.

Hers must be set up to allow file sharing in Public mode then I assume.

[Paul_oz53]

Create a share on your wife's PC and see if you can access it from both the Wiz and your PC.

I created a share. No errors. I mapped it on my PC and could access it. No errors. I set up a mountpoint for it on the T4. No errors. I tried to access the directory from the T4. "Directory '/media/autofs/DirComputer' does not exist." I checked the mountpoint setup and added ",vers=2.1" to the mount options, updated the share and then it worked when I accessed it.

I deleted the mountpoint for the share on my PC, rebooted the T4, and then created it again using exactly the same setup as for the share on my wife's PC. It still threw the error when I tried to access it.

The network browser will browse my wife's shares but will not browse mine. It looks like it is expanding the share list but not finding any shares to show. I can get it to browse mine by turning off password protected sharing, but doing so doesn't fix the problem with accessing the share.

I noticed that my wife's PC's network was Public. I switched it to Private. That made no difference to anything.

I will not pretend to have any expertise in networking beyond having had a similar problem a while back that I investigated over months. That it worked OK for you for a brief period tells me those other settings are correct. "vers=2.1" works but I am using "vers=3.0" on one wiz and nothing on the other but both see the Win10 shares.

My setup for years was to manually allocate IPs to each box and not use DHCP but I would get instances of missing shares. I usually went to the mount manager and forced it to reload, even if it showed a GREEN tick. Sometimes it took two attempts but usually, this would fix it. Sometimes not. If so, manually rebooting every device would eventually restore services.

My problem seemed to revolve around which device on the network was the Samba Master Browser. What you want it to be is a device that is always on but, when a device switches off there is a re-election process. There's a good chance yours is the T4, or else a PC and not doing a good job. Problem is, it forgets the list of shares if rebooted and has to re-establish it. The list is regenerated every 5 to 15 mins from what I can tell so a missing share would usually reappear sometimes after a delay.

Nowadays, my router has taken on that job and it rarely gets it wrong for more than 5 minutes. This is why I strongly recommend switching approaches - it is simply far better than when the T4 or a PC was the master browser.

[peteru]

Sounds like a problem with file system permissions on the PC. That would explain why you can mount the share, but see no content.

[engjs]

Sounds like a problem with file system permissions on the PC. That would explain why you can mount the share, but see no content.

Looks that way to me too, but I just can't find the bit that is different.

I tried disabling the firewall and the virus protection. Neither made any difference. I tried setting up a separate account on my PC and mounting everything through it. It made no difference.

I did find that if I turned the password protected sharing flag on my PC on it killed the mapping on my wife's PC, and turning it back off fixed it. That says to me that my PC is not authenticating visitors. But I can't make any sense of it. Even with the flag off the "Directory doe s not exist" error persists.

Anyway. I've moved the drive from my PC to my wife's PC and mounted it from there, and everything is running fine. I'm not entirely happy with this as a solution, but I'm also so sick of the whole thing that I just don't care anymore.

Thanks for your help guys.

[engjs]

Just for completeness.

When Windows tells you your username, don't believe it. It lies.

With the right username everything worked.

[MrQuade]

With the right username everything worked.

Excellent

Windows has made it needlessly difficult to manage local users now, which frustrates me to no end.

Normally, I'd advise that you create a non-admin local user account which you would use as a set of credentials for sharing media. You then share out your folders with that user as the only one with permissions. Even better if you can disallow that "user" from establishing interactive logins.

With Windows 10, MS desperately wants any user to be an actual person, and not just a set of credentials, so it wants you to link it to cloud accounts and all that garbage. You can still make local accounts, but it is now buried deep in the user interface

Generally, you want to avoid using your own PC's admin account for sharing media, because then your PC's admin username and password is being stored on other devices which may or may not be secure (or may even store credentials in plaintext!!).