35 replies to this topic

[peti]

Hi, I have the following issue:

I have some network shares mounted with Network Browser and automounts.xml. Everything is OK till I do not shut down the computer, where the shares are. After that, even if the computer is up again, when I open the recording list, spinning wheels appear and the only way is to restart the box from terminal.

Is there any way to fix this, or any workaround?

Thanks!

[SpaceRat]

I have some network shares mounted with Network Browser and automounts.xml. Everything is OK till I do not shut down the computer, where the shares are. After that, even if the computer is up again, when I open the recording list, spinning wheels appear and the only way is to restart the box from terminal.
Is there any way to fix this, or any workaround?

I've got exactly the same problem, but none of the developers was able to reproduce it.

It's a major pain in the *ss and the reason of 99.99% of my box' hard cold boots (Have to power off using power switch and repower).

[MiLo]

We're very much aware of the problem.

If you're using NFS, try using CIFS instead. It handles disconnects a lot friendlier.

If you feel like living on the cutting edge, install 'smbnetfs' (soon in the feed), that dynamically mounts everything. Looks a lot like Windows' Network Neighbourhood.

[SpaceRat]

If you're using NFS, try using CIFS instead. It handles disconnects a lot friendlier.

I'm using CIFS.

BTW: This problem is unique to OpenPLi. It doesn't happen with any other image (Probably limited to those not being based on OpenPLi ...).
On the other hand, "any other image" has a lot more problems of different nature ...

[peti]

I'm also using cifs. Didn't test other in images, just too many other issues

[SpaceRat]

I did some further investigation of this issue with two results:

a. It is not OpenPLi related, other images just use a mounter which will just circumvent the problem in many cases
b. Do not expect a fix, as the problem resides inside Linux itself and is known since at least 2005

The reason why OpenPLi users are more likely to experience this problem is simply the fact that it uses the plain method of mounting the shares permanently.

Only using autofs can "fix" the problem:
As autofs unmounts unused shares after a timeout (Which is even pretty short by default), there is a high probability the share simply won't be mounted when you reboot the server. That's all.

But as a matter of fact any Linux distro freezes when trying to access CIFS/SMB shares to which the connection got interrupted since mounting.
Reports of the problem can be easily found if you just imagine in which situations this problem is most likely to arise and google for the correct terms:
- Suspend/Resume on the server
- WiFi connected client was carried around after mounting the shares
- ...

[WanWizard]

Not entirely true (the statement in bold that is).

 

I can reboot my server without problems, and after that a simple access (like ls /media/hdd/movie) will reconnect the share and it's business as usual.

 

I do however use fstab entries, and not the automounter.

[SpaceRat]

It happens with fstab entries as well, I just tried on a friends Vu+ Duo as autofs is borked in OpenPLi 4.0 or with that specific kernel version or whatever.

So I guess it's not CIFS shares you are using but Samba shares.

I know that Samba is supposed to be a CIFS/SMB server, but that's exactly the point:
Insofar as Samba behaves incompatible to a real CIFS/SMB server (Which is as a matter of fact a Microsoft/IBM technology), it's simply not CIFS/SMB anymore.

At least Windows XP and Windows 7 handle a temporary disconnect gracefully, whether the server being a Samba server (E.g. my router, my E2 boxes,...) or a real CIFS/SMB server (Windows XP, Windows Server 2008R2, Windows 7, ...). Vice versa, Linux clients never reconnect gracefully as soon as the server is a real CIFS/SMB server. That means that Samba must contain modifications compared to CIFS (on which only the Linux client relies) which make it incompatible with Windows clients.

But sadly it's a waste of time to discuss this in here:
It's just unlikely to ever get fixed, because it will still be a kernel bug which is unfixed since more than 8 years. I don't see a big chance that some OpenPLi dev will now stand up and fix a long standing bug inside the Linux kernel if nobody else - especially nobody from the regular kernel devs - did in 8 years ...

Probably there even already is a "won't fix" comment somewhere in the code that Microsoft had misunderstood their own standards and needs to fix that ...

Edited by SpaceRat, 5 November 2013 - 01:08.

[Rob van der Does]

I've been using AutoFS for a week or so, and I must say: it's amazing. Never ever any problems with mounts that weren't available during boottime (I used fstab until then) and as soon as a mount springs to live it's accessible.

This applies to both cifs and nfs mounts.

[WanWizard]

@SpaceRat,

 

correct, no Windows in this house.

[SpaceRat]

I've been using AutoFS for a week or so, and I must say: it's amazing. Never ever any problems with mounts that weren't available during boottime (I used fstab until then) and as soon as a mount springs to live it's accessible.
This applies to both cifs and nfs mounts.

Yeah, that's probably the reason why most images use that ...

However, I can't get autofs to work on a friend's Vu+ Duo² running OpenPLi 4.0.

I installed the package
opkg install autofs
and added the shares from his automounts.xml to his /etc/auto.net in exactly the same way as I moved my shares from my automounts.xml to my /etc/auto.network:

Dokus -fstype=cifs,ro,soft,rsize=8192,wsize=8192,user=Karl\ Dall,pass=Rhabarber ://192.168.3.20/Dokus
Filme -fstype=cifs,ro,soft,rsize=8192,wsize=8192,user=Karl\ Dall,pass=Rhabarber ://192.168.3.20/Filme

a.) Why the change from auto.network to auto.net between autofs from OpenPLi 3.0 and OpenPLi 4.0?
b.) It just DNGN (Does Nothing, Goes Nowhere) on his box. The folder /media/net gets lost on every boot and no shares are mounted. On my box, it works like a charme.

autofs/automounter was completely modified in between:
Different config files (No auto.misc, auto.hotplug, auto.net on OpenPLi 4.0; old auto.network renamed to auto.net), different pre-requisites (procps required on OpenPLi 3.0 but not on OpenPLi 4.0), automounter 5.x rather than 4.x.

mount.cifs via automounts.xml or fstab works on both, his OpenPLi 4.0 Duo² and my OpenPLi 3.0 Ultimo, with exactly the same Linux kernel bug (freeze after temporary unavailability of the share(s)). autofs works only on my box.

[peti]

Guys, try smbnetfs, I'm using it more then a month, and it handles the unreachable shares great. 

[SpaceRat]

petike, on 06 Nov 2013 - 08:16, said:
Guys, try smbnetfs, I'm using it more then a month, and it handles the unreachable shares great.

I can confirm that, at least for shares that were available when smbnetfs started.

So for OpenPLi 3.0 U suggest switching to autofs and for OpenPLi 4.0 to smbnetfs.

smbnetfs has one major disadvantage though:
It can only mount shares that are visible in the "neighborhood".

This might be sufficient for most people, but
a.) you can make computers invisible there (Less for safety reasons but more for performance, it's at least one service less on the machine offering the shares)
b.) machines in different subnets will also be invisible, e.g. ones connected through VPNs.

So it would be best if autofs would be fixed for OpenPLi 4.0.

[MiLo]

So it would be best if autofs would be fixed for OpenPLi 4.0.

Sure, just send in patches with the fixes.


All I know is that autofs is the same as what the rest of the world is using. It's a newer version than what used to be in OpenPLi 3, so there are bound to be differences.

What I noticed is that it refuses to create directories in spite of what the documentation said it would do. For some reason, you still have to manually create whatever mountpoint you plan to use and then it will work.

I've actually been looking at a way to integrate autofs directly into E2, that is, just using the kernel functionality without having to hack all kinds of config files. Lack of time has put that on the "maybe in a year or so" lane.

[Xana]

Hi, I have the following issue:

I have some network shares mounted with Network Browser and automounts.xml. Everything is OK till I do not shut down the computer, where the shares are. After that, even if the computer is up again, when I open the recording list, spinning wheels appear and the only way is to restart the box from terminal.

Is there any way to fix this, or any workaround?

Thanks!

 

Hi,

any advances on the "E2" to fix this problem ?

 

Thank's

[SpaceRat]

I have some network shares mounted with Network Browser and automounts.xml. Everything is OK till I do not shut down the computer, where the shares are. After that, even if the computer is up again, when I open the recording list, spinning wheels appear and the only way is to restart the box from terminal.

any advances on the "E2" to fix this problem ?

No, it's a Linux bug the Linux devs are too stupid to fix.

It will happen on your Desktop machine running Linux as well ...
Uhm ... wait ... Desktop? Linux?
Ok. Forget it.
It's beyond Enigma2 devs control however, as it needs to get fixed inside the Linux kernel ...


You can work around the problem by using either autofs or smbnetfs.
autofs is the better choice because it also works for servers not visible on the network (i.e. that have to be accessed using their IP).

Just telnet/ssh to the box and do
opkg install autofs

then add your shares to /etc/auto.net, like this

# automounter configuration
Schlafzimmer            -fstype=cifs,rw,user=root,pass=YourPaswword                ://192.168.1.17/Harddisk
Dokus    -fstype=cifs,ro,user=Your\ username,pass=YourPaswword   ://192.168.1.20/Dokus
Filme    -fstype=cifs,ro,user=Your\ username,pass=YourPaswword   ://192.168.1.20/Filme
Porn     -fstype=cifs,ro,user=Your\ username,pass=YourPaswword   ://192.168.1.20/Porn
TV-Serien -fstype=cifs,ro,user=Your\ username,pass=YourPaswword  ://192.168.1.20/TV-Serien

Whitespaces inside username and/or pass have to be escaped using a backslash \ as shown above

chmod 600 auto.net
after that.

Now
cd /etc/init.d
and edit the file "autofs" there.

Between these lines

 	echo -n "Starting $prog: "

	# Make sure autofs4 module is loaded

add "mkdir -p /media/net" to work around the problems a.) autofs forgets to create those dirs and b.) it will stupidly remove them again and again

The result should look like this:

 	echo -n "Starting $prog: "

	mkdir -p /media/net
	# Make sure autofs4 module is loaded

Works like a charm for me.

[Xana]

@SpaceRat: many thank's

I will give it a try.

 

Cheers

[nietgiftig]

@SpaceRat

 

Thanks for the clean and complete write-up

[SpaceRat]

@SpaceRat
 
Thanks for the clean and complete write-up

That was easy ... I had to do it myself like half an hour ago

[Xana]

@SpaceRat
 
Thanks for the clean and complete write-up

That was easy ... I had to do it myself like half an hour ago

 

It works like a charm ... thank's