Media over network share unavailable ... please help!

[colinjones]

Zaerc/Royw - Thanks.

Zaerc - actually, before I came across the auto.Pluto.... file, in desparation I tried tinkering with that exact setting. But not knowing anything about how these protocols are used or what Linux calls them, I took a shot in the dark and tried "smb"! Didn't seem to do anything - no improvement, and no errors... maybe smbfs would have made the difference.

Do you know why it requires smbfs? This is an OEM standard XP install in a workgroup. But when I try a share on my work XP Professional, with all the work policies in a domain etc, it does exactly the same thing....

If there is something fundamental about some machines not accepting CIFS, then shouldn't the pnp script detect which it is, and insert the correct value in that attribute now that the patch is in place?

[colinjones]

Yep, that seems to have fixed it, as long as I have a username and password in there as well. But have converted the script back, and changed the cifs to smbfs, rebooted and it all seems good!

Thanks

[royw]

I've been following this thread closely because I have a similar problem with an nfs share.  Can rip to nfs share, then file's permissions are screwy.  Change them to 777 and updatemedia insists device is offline.  Manually change config to online, run updatemedia, device is back to offline.  Filename search finds files.  Media File Sync finds files.  Title browsing does not find files.  I.e., pretty much the same symptoms you were having with cifs...

Really looking like something above the underlying protocol is misbehaving.

Currently I have a new network card on order as kubuntu locks up when transferring several dvd files to nfs share.  I'm going to replace the card in a few days then dig heavy into the db & scripts.

Have fun,
Roy

[colinjones]

Roy - if you can browse your shares from KDE, play the media, and search (not browse) for the media in LMCE and play it, then it is definitely the same issue. All this time my gut told me it was a logic issue in determining whether the "device" was online or not. I think this has been vindicated by my experience.

Even UpdateMedia was able in its first phase of the output window, to find and connect to the files and grab attributes, etc, but then bizarely in the same process at the end of the run, suddenly say that the device was offline! Even if I changed the artwork, embedded tags or the file name, it would see that an log it in the output window proving that it was "online" but then say the device is offline.

Not using NFS in any way nor know much about it, except that the script I edited definitely mentions it at points, so I would start there... hope it doesn't take you as long as it did me!

[royw]

Howdy,

I may have found the nfs problem.  In /usr/pluto/bin/StorageDevices_StatusRadar.sh there are two typos in the nfs area:

Code: [Select]

for NFSShare in $NFSShareList ;do
if [[ "$NFSShare" == "" ]] ;then
continue
fi

Share_ID=$(Field "1" "$NFSShare")
                        Share_Name=$(Field "2" "$NFSShare")
                        Share_Username=$(Field "3" "$NFSShare")
                        Share_Password=$(Field "4" "$NFSShare")

## Test if the share is still in the list
showmount -e $Device_IP | cut -d ' ' -f1 | grep "^${ShareName}$"
isShareInList=$?

if [[ "$isShareInList" != "0" ]] ;then
Log "Share $Share_ID ($Share_Name) is not advertised by the nfs server"
SetDeviceOnline "$Share_ID" "0"
continue
fi

                        ## See if the share is mountable
                        mountDirTemp=$(mktemp -d)
                        mount ${Device_ID}:${Share_Name} $mountDirTemp 1>/dev/null 2>/dev/null
                        isShareMountable=$?

1) The variable $ShareName in the showmount command should be $Share_Name
2) The variable $Device_ID in the mount command should be $Device_IP

BTW, it looks like this is the script responsible for assigning device online/offline status.  You can manually run it with the background option to see the log messages (I couldn't find the messages in any log file):

  sudo /usr/pluto/bin/StorageDevices_StatusRadar.sh background

To replace in a running system you will need to kill the currently running script, then spawn the changed script to the background:

  $ ps -ef | grep StorageDevices_StatusRadar
  root      AAAA     1  0 19:06 ?        00:00:00 SCREEN -d -m -S StorageStatusRadar /usr/pluto/bin/StorageDevices_StatusRadar.sh background
  root      BBBB  8323  0 19:06 pts/6    00:00:01 /bin/bash /usr/pluto/bin/StorageDevices_StatusRadar.sh background
 
  $ sudo kill -9 AAAA BBBB
  $ sudo /usr/pluto/bin/StorageDevices_StatusRadar.sh

This did eliminate the device is offline issue with updatemedia for my nfs share...

Have fun,
Roy

[dopey]

colinjones, have you tried using a fake username and password. Even though Windows XP has the share anonymous smbfs still requests a password to mount. I never matters what you use for a password, but it will always ask for one. CIFS may have the same quirk.

Of course, that should be handled by the script, but I don't have it handy to say if it actually does.

[royw]

I'm very happy to report that NFS shares are now working for me.  It was a combination of three issues:

• The typos in StorageDevices_StatusRadar.sh described previously.
• Figuring out the correct permissions on the share (documented on the wiki at http://wiki.linuxmce.org/index.php/Howto:_Using_Network_Shares#NFS_Server_Hints).
• A bad gigabit switch (Netgear GS105) that was limiting read speed from the NFS share to about 200KB/s.

I opened a Mantis ticket for the first issue: http://mantis.linuxmce.org/view.php?id=3915.

The last issue was found after reading http://ubuntuforums.org/showthread.php?t=183636.

Have fun,
Roy

[colinjones]

colinjones, have you tried using a fake username and password. Even though Windows XP has the share anonymous smbfs still requests a password to mount. I never matters what you use for a password, but it will always ask for one. CIFS may have the same quirk.

Of course, that should be handled by the script, but I don't have it handy to say if it actually does.

Dopey - no I didn't try that, I had already created a "media" account and password and just used that instead. But you're right, it should really be handled in the script as it is on the smbfs side, not the Windows side. Perhaps we should have that in there as well as the determination of whether it should use smbfs in the first place or cifs?

Well done Royw!

[Randykc]

I found this thread after experiencing the same issue this weekend. what ended up being the final resolution colinjones?

I made the corrections to the StorageDevices_StatusRadar.sh file and got my media to display.  Thought I had it fixed until I came home yesterday and found my Core/Hybrid machine hung and I had to reboot. When it came back, my Windows shared media were missing again.  I went directly to the admin page and the Online checkbox for all of my window shares were not checked. I checked the Online box, hit Save, closed the admin page, went back into the admin page, and again, the box was not checked.

I think I'm close to getting it to work, so I don't want to make any drastic changes. Since I can use search and find the media, does that mean the entries are still in the database?

Also, since I can play the windows shared media after finding it in a search, would that indicate that my permissions, firefall, network, etc is valid?

[colinjones]

You definitely seem to have the same problem. When that tick box unticks itself a few seconds later, it is being marked offline.

The only way I could fix it was (using 0710beta3 or 4) putting smbfs in the config of the share instead of cifs. This fixed the protocol problem. Also, putting a user name and password in both the share config and server config devices was necessary - NOTE - without this it was unable to see the share as online so didn't present the media in the browser. However I could still browse and play the media just fine in KDE desktop, so that may have been the case for the search function in LMCE.

Recently I started getting smbfs problems that was freezing Linux - I switched back to cifs and it worked fine!!! I had done nothing else but all seemed good.

I have now installed beta 4 and either seems to work! But I note that from the changelog it suggests that the default has been changed to smbfs - this is not true, my share was created as cifs just as with previous versions.

[Randykc]

Excellent.  Just what I was looking for.  I haven't entered a username and password into the server configs yet, but that was on my to-do list tonight. Didn't know if you went back to cifs from smbfs after the typos were discovered in StorageDevices_StatusRadar.sh.

Thanks for the update.

[colinjones]

Frankly, I don't know which to use (cifs or smbfs) at this point - haven't received any meaningful answers on the underlying protocol issue to this... with cifs I feel that at any time the mounting issue could come back, with smbfs the freezing issue could come back! I would prefer to use cifs as it is apparently better supported...

[orionsune]

Don't know how related this is, but i've also noticed, I can't use characters like !@#$%^&*()_+|<>?,./-=[]\ in my password or it will fail to mount.  I had to create another user account with a simple password specifically for lmce to use.

[Randykc]

That did it. I noticed that I had switched from cifs to smbfs but without the username/password entry. I added a username/password and switched back over to cifs and it all started showing up again.