"No such file or directory" after creating mount

[Altimes]

Anyone had trouble mounting U4 on T4 ?

I have encountered an intractable issue when I discovered that our T4 could not change location (yellow) to the U4 Movie share. Error dialog showing as "/media/autofs/BEYONWIZU4_Movie/ No such file or directory". OK, a cursory look around and all looked OK, but what the heck, it's UNIX sometimes stuff "just happens".

So, I have tried just setting up again. Used the GUI to delete the mount, reboot, check that it was all gone (it was) and setup again. Browse to the U4, select and save. Sadly still no joy, same complaint. OK let's look a little more carefully.

If I try to manually mount the U4 on its nominated mount point, I get the "No such ...." complaint. If I try a manual mount on a temporary created location, it works fine and I can traverse the remote directory.

Some outputs below from my tests in case I am just not seeing the bleeding obvious (never happened of course )

Try to traverse into remote:

root@beyonwizt4:/mnt/autofs# ls
BEYONWIZU4_Movie NAS_Movie NAS_TV WizVideoNAS
root@beyonwizt4:/mnt/autofs# ls -sal
0 drwxr-xr-x 6 root root 0 Jan 1 1970 .
0 drwxrwxrwt 6 root root 120 Oct 12 11:08 ..
0 dr-xr-xr-x 2 root root 0 Jan 1 1970 BEYONWIZU4_Movie
0 dr-xr-xr-x 2 root root 0 Jan 1 1970 NAS_Movie
0 dr-xr-xr-x 2 root root 0 Jan 1 1970 NAS_TV
0 drwxr-xr-x 2 root root 0 Oct 5 18:26 WizVideoNAS
root@beyonwizt4:/mnt/autofs# cd ./BEYONWIZU4_Movie/
-bash: cd: ./BEYONWIZU4_Movie/: No such file or directory
root@beyonwizt4:/mnt/autofs#

Contents of auto.network:

root@beyonwizt4:/etc# cat auto.network
# automounter configuration
NAS_Movie -fstype=cifs,user=Wiz,pass=adgjmptw,rw,iocharset=utf8,vers=2.1,cache=loose ://192.168.1.30/video
WizVideoNAS -fstype=cifs,user=Wiz,pass=adgjmptw,rw,iocharset=utf8,vers=2.1,cache=loose ://192.168.1.30/WizVideo
NAS_TV -fstype=cifs,user=Wiz,pass=adgjmptw,rw,iocharset=utf8,vers=2.1,cache=loose ://192.168.1.30/TV
BEYONWIZU4_Movie -fstype=cifs,user=guest,pass=,rw,iocharset=utf8,vers=2.1,cache=loose ://192.168.1.24/Movie
root@beyonwizt4:/etc#

Successful non-auto mount:

root@beyonwizt4:/tmp# mkdir abc
root@beyonwizt4:/tmp# mount.cifs //192.168.1.24/Movie ./abc -o user=guest,pass=
root@beyonwizt4:/tmp# ls abc
Aerial Asia Just For Laughs Monty Python's Flying Circus Movies Secrets Of The Museum
root@beyonwizt4:/tmp#

So it *looks* like an issue with the directory being created in the autofs directory but I am buggered if I can see any difference with the NAS ones that all work just fine. Or the auto mounter just doesn't like me

Any suggestions on what I might try next ?

I have just applied the latest beta online update (vain hope that it might help).

Firmware version: beyonwiz 19.3.20201011 (19.3-346-g6461e3a)
Kernel / Drivers: 3.14.2 / 20180416

TIA Alan.

[MrQuade]

Try recreating the mount, and then look at /var/log/messages to see if any error is generated there.

There is a known problem with the T3 and V2.1 SMB mounts at the moment, but the T4 and other boxes were not affected by this. Plus the fact that your NAS connections are working with version 2.1 mounts means it isn't that.

IP and connectivity seems ok since the manual mount works.

Have you tried deleting the mount, and then re-creating it with a different name? (making sure you always press OK to dismiss the popup that is displayed after mount creation, since pressing EXIT will mess things up).

[Paul_oz53]

My T4 can access both U4s fine but the mount options do NOT include ",vers=2.1".

I suspect this is a hangover from restored settings as I haven't consciously edited these mounts recently.

[Grumpy_Geoff]

My T4 can access both U4s fine but the mount options do NOT include ",vers=2.1".

Same same me - except I've only one U4.

[Altimes]

Thanks for the responses. BTW the "vers=2.1" simply appeared with a GUI creation of the mount. No changes on my part, it would seem to be being automagically inserted.

GG's first response was very useful, thanks, in messages I see multiple copies of

Oct 12 14:01:21 beyonwizt4 daemon.err nmbd[544]: query_name_response: Multiple (2) responses received for a query on subnet 192.168.1.20 for name WORKGROUP<1d>.
Oct 12 14:01:21 beyonwizt4 daemon.err nmbd[544]: This response was from IP 192.168.1.24, reporting an IP address of 192.168.1.24.
Oct 12 14:06:21 beyonwizt4 daemon.err nmbd[544]: [2020/10/12 14:06:21.369012, 0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)

Which I *think* is trying to tell me that I somehow have multiple master browsers for WORKGROUP. You suspect that for M$ it would be far, far too much work to annotate <1D> with something comprehensible

[Grumpy_Geoff]

Thanks for the responses. BTW the "vers=2.1" simply appeared with a GUI creation of the mount. No changes on my part, it would seem to be being automagically inserted.

Yes, defaulted in more recent f/w.

GG's first response was very useful, thanks, in messages I see multiple copies of

That was MrQuade

[Altimes]

Opps. Transfer thanks to Mr Quade Just blame trevor....

OK, So I shutdown the U4, the T4 got promoted to Master (I see that in messages). However...... problem persists, so I thought that I would test making it a permanent mount (fstab option) with a different name. Oddly the new name still shows up in the autofs directory which may be correct, but seems an *odd* placement.

Problem persists.

Looking at the messages I now see;

Oct 12 15:06:51 beyonwizt4 daemon.info automount[480]: rmdir_path: lstat of /media/autofs/etc failed
Oct 12 15:06:51 beyonwizt4 daemon.info automount[480]: rmdir_path: lstat of /media/autofs/VIDEO_TS.IFO failed
Oct 12 15:06:51 beyonwizt4 daemon.info automount[480]: rmdir_path: lstat of /media/autofs/VIDEO_TS failed
Oct 12 15:06:51 beyonwizt4 daemon.info automount[480]: rmdir_path: lstat of /media/autofs/sal failed
Oct 12 15:06:51 beyonwizt4 daemon.info automount[480]: rmdir_path: lstat of /media/autofs/logs failed
Oct 12 15:06:53 beyonwizt4 daemon.info automount[480]: key "BEYONWIZU4_Movie" not found in map source(s).
Oct 12 15:06:54 beyonwizt4 daemon.info automount[480]: rmdir_path: lstat of /media/autofs/BEYONWIZU4_Movie failed
Oct 12 15:12:15 beyonwizt4 daemon.info automount[480]: key "VIDEO_TS" not found in map source(s).
Oct 12 15:12:15 beyonwizt4 daemon.info automount[480]: key "VIDEO_TS.IFO" not found in map source(s).
Oct 12 15:13:02 beyonwizt4 daemon.info automount[480]: rmdir_path: lstat of /media/autofs/VIDEO_TS.IFO failed
Oct 12 15:13:02 beyonwizt4 daemon.info automount[480]: rmdir_path: lstat of /media/autofs/VIDEO_TS failed
Oct 12 15:13:04 beyonwizt4 daemon.info automount[480]: key "BEYONWIZU4_Movie" not found in map source(s).
Oct 12 15:13:05 beyonwizt4 daemon.info automount[480]: rmdir_path: lstat of /media/autofs/BEYONWIZU4_Movie failed

All of which looks *very* odd. References to DVD like components and the old name being seen by the daemon start to make me think that some internal database has become seriously buggered. Maybe it is time to surrender, reflash from USB and setup from scratch without a restore. Unless there is some way for resetting the network mount stuff in isolation.

TIA. Alan

[Paul_oz53]

Thanks for the responses. BTW the "vers=2.1" simply appeared with a GUI creation of the mount. No changes on my part, it would seem to be being automagically inserted.

GG's first response was very useful, thanks, in messages I see multiple copies of

Oct 12 14:01:21 beyonwizt4 daemon.err nmbd[544]: query_name_response: Multiple (2) responses received for a query on subnet 192.168.1.20 for name WORKGROUP<1d>.
Oct 12 14:01:21 beyonwizt4 daemon.err nmbd[544]: This response was from IP 192.168.1.24, reporting an IP address of 192.168.1.24.
Oct 12 14:06:21 beyonwizt4 daemon.err nmbd[544]: [2020/10/12 14:06:21.369012, 0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)

Which I *think* is trying to tell me that I somehow have multiple master browsers for WORKGROUP. You suspect that for M$ it would be far, far too much work to annotate <1D> with something comprehensible

Yes, as noted by others, it's now the minimum default for SMB security reasons. However, AFAIK samba version 2 does not rely on a master browser in the same way as version 1.

That you seem to have multiple master browsers is very much a "feature" of version 1. In fact there is an election every 15 minutes for the role (depending on the configuration). The role can jump from device to device but only one device can hold the role at a time. I suspect that you are seeing changes due to the election process. Any glitches in your network will trigger a new election. For stability it is best to allow an always on device like a router to be the master browser but that is easier said than done.

I had much SMB frustration until I set fixed IPs allocated by MAC address in the router. Using fstab was not a solution for me.

[MrQuade]

All of which looks *very* odd. References to DVD like components and the old name being seen by the daemon start to make me think that some internal database has become seriously buggered. Maybe it is time to surrender, reflash from USB and setup from scratch without a restore. Unless there is some way for resetting the network mount stuff in isolation.

Yea, something has its knickers in a twist allright.

I am not sure how the media player opens .iso image files, but I wouldn't have thought it literally did it as an automount, and even then, why the files would appear in the automount root.

[Grumpy_Geoff]

References to DVD like components and the old name being seen by the daemon start to make me think that some internal database has become seriously buggered.

I have that "cached" junk appear too.
Earlier today -

Code: Select all

root@beyonwizu4:~# grep automount /var/log/messages
Oct 12 07:39:36 beyonwizu4 daemon.info automount[782]: key "NAS" not found in map source(s).
Oct 12 07:39:42 beyonwizu4 daemon.info automount[782]: key "logs" not found in map source(s).
Oct 12 11:35:05 beyonwizu4 daemon.info automount[782]: key "VIDEO_TS" not found in map source(s).
Oct 12 11:35:05 beyonwizu4 daemon.info automount[782]: key "VIDEO_TS.IFO" not found in map source(s).

But some of it has gone after a reboot -

Code: Select all

root@beyonwizu4:~# grep automount /var/log/messages
Oct 12 15:13:21 beyonwizu4 daemon.info automount[795]: key "NAS" not found in map source(s).
Oct 12 15:13:27 beyonwizu4 daemon.info automount[795]: key "logs" not found in map source(s).

But as soon as I browse /media/autofs the extra junk re-appears -

Code: Select all

root@beyonwizu4:~# grep automount /var/log/messages
Oct 12 15:13:21 beyonwizu4 daemon.info automount[795]: key "NAS" not found in map source(s).
Oct 12 15:13:27 beyonwizu4 daemon.info automount[795]: key "logs" not found in map source(s).
Oct 12 15:35:39 beyonwizu4 daemon.info automount[795]: key "VIDEO_TS" not found in map source(s).
Oct 12 15:35:39 beyonwizu4 daemon.info automount[795]: key "VIDEO_TS.IFO" not found in map source(s).
Oct 12 15:35:39 beyonwizu4 daemon.info automount[795]: key ".e2settings.pkl" not found in map source(s).

None of those "shares" are defined on the U4.

[Paul_oz53]

Hi Altimes,

Only if you're inclined to determine if it's a settings issue or not you could try it with and without.

If you save a backup today and USB reflash tomorrow you could do a minimal setup, save another backup and see if it works ok.

Then, using advanced restore (available in the plugin menu under software management) you can revert to the previous setup and see if it breaks. If so, you will have the good backup as a basis for completing the setup. You could also try an earlier backup but noting that timers will be out of date.

Of course, you may not want to bother with this if it's working ok.

Cheers, Paul

[sub3R]

... Maybe it is time to surrender, reflash from USB and setup from scratch without a restore.

I’ve only glanced through your posts so I may have missed it. Have you tried re-flashing via USB then restore settings?

Our usually rock solid LAN had troubles a few days ago after an unplanned power outage. Both U4s were running beta 19.3 20200927 at the time. After power was restored I kept getting the No such file or directory (I think that was the error message) when I tried to view one U4 from the other U4 over the LAN, but it worked fine the other way. I spent hours trying everything that I could think of without success. I eventually got it working by re-flashing f/w via USB with restore settings to 19.3 20200921 then an on-line f/w update with restore settings to 19.3 20200927 on the U4 that the other U4 couldn't see.

So before you try re-flashing via USB without restore settings, try re-flashing via USB with restore settings.

One thing I did notice, before re-flashing via USB some of my SMB mounts on the U4s had changed from vers=3.0 to vers=2.1.

[Altimes]

OK, so I have eventually managed to get some time on the T4 to try a few things. TL;DR Problem has gone away (for now)....

Reflashed to recent beta, go through basic setup (without restore), attempt to setup auto mount for U4 from T4, bugger, same problem. OK, this is household machine, better put it back in production. Restore from backup, setup beta feed, apply current updates, reboot. Lo and behold, it works as expected

A little more poking around showed that my last attempt had been to change from autofs to fstab. So, perhaps the root cause ? Change back to autofs (U4 is only occasionally on). Still works, go figure....

Thanks to all for aid and advice.

Alan.

[Paul_oz53]

OK, so I have eventually managed to get some time on the T4 to try a few things. TL;DR Problem has gone away (for now)....

A little more poking around showed that my last attempt had been to change from autofs to fstab. So, perhaps the root cause ? Change back to autofs (U4 is only occasionally on). Still works, go figure....

Thanks to all for aid and advice.

Alan.

I gave up on fstab years ago because I had to reboot everything in a specific order to restore connections. Autofs is definitely better for stable connections.