35 replies to this topic

[nietgiftig]

@SpaceRat

 

after installing autofs :

 

Just to be sure, the /etc/init.d/autofs does not have the  <echo -n "Starting $prog: "> line.

 

Do you have openpli3 or 4

Could there be a package difference?

Attached Files

•  autofs.txt   14.33KB   62 downloads

Edited by nietgiftig, 17 December 2013 - 11:23.

[SpaceRat]

Do you have openpli3 or 4

Now OpenPLi 4.0
I f*cked up my OpenPLi 3.0 yesterday, that's why I had to re-install and I used the opportunity for an upgrade.

Could there be a package difference?

There are:
OpenPLi 3.0 uses autofs 4.x which works fine without that "patch", while OpenPLi 4.0 comes with autofs 5.x which has the "I will refuse to mount without the top level dir of a mount point already existing, but I will always delete that one to ensure I always fail" bug as MiLo pointed out earlier in this thread.

As long as you use OpenPLi 3.0 and OpenPLi 3.0 continues to use autofs 4.x, you do not need to modify /etc/init.d/autofs

Edited by SpaceRat, 17 December 2013 - 11:35.

[falko]

root@dm500hd:~# opkg install autofs
Installing autofs (5.0.7-r8) to root...
Downloading http://downloads.pli-images.org/feed...2el/autofs_5.0.

7-r8_mips32el.ipk.
 Removing any system startup links for autofs ...
Configuring autofs.
 Adding system startup for /etc/init.d/autofs.
Starting automount: Error: failed to load autofs4 module.
root@dm500hd:~#

 

 

Help

 

Error install autofs my dm500hd openpli4

[arnask]

After reflashing firmware i cant mount time capsule using CIFS. Is there any solution?

[Satpal]

What box? At the moment there seems to be a problem on Vu+ Solo and Duo after some modules like ext4 and cifs were removed from the image. Did you try to install them manually with:

 

opkg update

opkg install kernel-module-cifs

opkg install kernel-module-ext4

init 6 # reboot

 

Didn't work for me but who knows. I'm using nfs for now. But I don't think you should have reopened this old post for this new and different issue.

[sat4all69]

I have that problem on my VU+duo running last version of Openpli. The box hangs when trying to access network shares located on my Win 8.1 PC after a reboot.  Very annoying "bug".

[WanWizard]

And is that PC up and running at that moment?

 

If not, it's just waiting for a timeout. You should not create mounts to devices that are not always there...

[SpaceRat]

No server can be guaranteed to be "always there".
Clients must handle temporarily unavailable servers gracefully.

Well, except diskless workstations maybe but that's probably the reason why they are that "widespread".

[sat4all69]

It is just my desktop PC, I am just a normal user ... It runs almost all the time but sometimes I have to reboot it for maintenance (well, its windows ...). Then if I want to watch something from the network on my VU+duo it crashes ... Everytime I reboot my PC iI have to reboot the TV box after ... it's quite odd ;-)

[SpaceRat]

Even professional servers sometimes have to be taken down for maintenance, although much less often.
What WanWizard is trying to sell to you: "It's not a bug, it's a feature."

While it's often claimed that was a Microsoft motto, it was in fact invented by *ix guys.

Actually the bug you observe has already been declared a feature by Samba.org/Linux long time ago, so do not expect a fix.

There is only a work-around for this problem, which is to use autofs to mount CIFS shares.
As autofs only mounts on demand and unmounts ASAP afterwards, it's highly unlikely for the feature to occur, unless it's really a bug (You simply can't expect normal operation when the server disappears while being accessed ...).

To make OpenPLi more fun, OpenPLi has included a different feature in autofs however, the "I do not work at all until the user fixes me manually" feature.
It's part of the OpenPLi experience that any new user who wants to use network shares first has to search the forum for the work-around and apply it manually.

[WanWizard]

Don't put words into my mouth friend, I am perfectly capable of speaking myself, thank you.

 

It's absolutely not a feature, it's a bloody nuisance.

 

But it's also the kernel that attempts to create the connection, and then waits for it (or a timeout) before continuing. Which is outside our control. Fact remains that standard linux mounts were (and are) designed to connect to servers that are always there. NFS is even worse than CIFS, it will wait forever if you haven't configured measures against that manually.

 

Autofs is, it being a userspace and runtime implementation, absolutely a much better solution.

 

And your last sentence is again the absolute negative rubbish you always barf out in this forum. Trying to make it look as if we do something deliberately.

 

OpenPLi is open source, so if you have a better solution, implement it, send a patch, make a user happy? Clearly we don't come around to doing it ourselfs, given the lack of time and the relative priority of this issue...

[SpaceRat]

For the zillionst time:
http://forums.openpl...es/#entry392418

Quote:
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

The above is no less than a human readable patch.
Just do it, diff it and you got your patch.
Estimated time needed: 2 min for you guys, as you already got your local clones of your git.
Estimated time for me: Much longer, as I would need to clone/checkout first.

or

See this autofs recipe (Adding the volatiles file is the key):
https://github.com/o...-daemons/autofs

 

Clearly we don't come around to doing it ourselfs, given the lack of time and the relative priority of this issue...

If no OpenPLi dev has 2 minutes time left to adopt a fix for a major problem, OpenPLi should think about if it makes sense to keep up an own distro.

But in reality, MiLo and others have done patches for less, e.g. "Debug cosmetics" or inverting plugin setting defaults, so there is plenty of time.

[littlesat]

So you telling me that we only need to add

 

mkdir -p /media/net

 

in /etc/init.d/autofs and the issue is solved?

 

-or-

 

Change the autofs recipe by adding the volatiles file?

 

Could you post a patch please so I can do an easy git am?

Edited by littlesat, 7 May 2015 - 10:56.

[SpaceRat]

Yes.
So far it has fixed the problem for everyone who tried.

The problem is that this directory keeps disappearing, so just recreating is the obvious work-around.

Edited by SpaceRat, 7 May 2015 - 10:58.

[sat4all69]

Good evening. I have exactly followed the procedure you described but it's till hanging when accessing network drives on windows PC. Not fixed.

[WanWizard]

autofs is a solution for mount points that are not there when the box (re)starts.

 

It is not a solution for loss of existing connections, your box will hang as solid and long as with any other way of mounting. It is also no solution when you try to make a connection and the target isn't there, you will still have to wait for the timeout of the kernel driver.

 

It's the main reason we have always said that autofs is not the holy grail when it comes to mounts, and doesn't solve most of the problems (it solves only one of them).