Ok. I have done some pretty intense research regarding this matter. All I have found are old topics, where the problem was never solved. Hardly any topics even had suggestions on how to resolve this problem. The topics that did offer suggestions were links to a set of generic instructions on how to manually add shares through web admin (which didn't work for any previous posters or myself).
From the begining. Anyone feel free to blow my mind with whatever it is i'm missing... please..
1. Installed Linux MCE DVD 710 Beta 3
2. Ran through wizards, took mostly default settings.
3. MCE finds my windows box's shares. (asks for username/pw, etc... everything proceeds with the share wizards fine... no indication of any problems)
4. I go to look at my media and it isn't there.
5. The generic syslog's in the /var/log tell me absolutely nothing.
6. I search the forums...
7. I find out where MCE tries to mount the samba shares... (/mnt/devices/##)
8. I issue smbmount command to manually mount my share in (/mnt/device/##) and recieve an error that the folder doesn't exist.
9. I check the folder contents of /mnt/device and there are no folders that correspond with the symbolic links created by the wizard in /home/public/data/other.
10. I issue a "mkdir" command to create the associated number of my share (my case 33). It says permission denied.
11. I smack myself and then issue a command "sudo mkdir" and again... permission denied.
12 I use "su" to become root completely and make the folder again... permission denied.
13. So I issue an "ls -la" to see if maybe the folder exists but is hidden... it is not.
14. I decide I am too frustrated and came to the conclusion this product does not work out of the box, even with matching hardware as seen on the demo. word of the day = bullshit
15. Just to see if MCE even catalogs my movies correctly, I create a folder in /home/public/data/other called test. So I have /home/public/data/other/test...
16. I manually mount my windows share at the command line into /home/public/data/other/test...
17. It mounts successfully. Wow that was an easy command to use... wonder what MCE's problem is?
18. (Continuing on) I issue the "UpdateMedia" command at the command prompt.
19. I go back into the orbiter and go look at media, OMFG IT'S THERE.. ALL MY MEDIA IS THERE!!!
So... is there some sort of known issue or am I a rare case? Wtf I have no idea why the hell mce cannot properly mount my shares. Except maybe MCE can't create the /mnt/device/## folder for the mount point to go. Because I certainly was not able to create any folder in there, even as root. I tried different folder names too, not just the numbers associated with my symbolic links.
Please, this is probably the only time in my life I desperately want someone to make me feel stupid and talk down to me like i'm at idiot and explain to me what is wrong with me and why i'm not smart enough to figure out this supposedly "out of the box" product.
You aren't stupid! But I am assuming that if you have read the forums for similar issues you will have seen the advice many times - do not attempt to mount your drives manually.... LMCE has an automated system for doing this transparently integrated into the software. 1. if you do it manually you will almost certainly screw this mechanism up, 2. doing it manually is addressing the symptom not the root of the problem, there is something wrong with the system; fix it, and the shares will mount themselves.
I have no idea how you can guarantee roll-back of all the mounts and so on that you have done manually, and any associated confusion/corruption it may have caused to LMCE's file system management - so to be honest, I would rebuild from scratch again just to be sure. Only takes 30 mins from the DVD! But there's nothing more annoying than going around in circles for hours troubleshooting only to find that you fixed the issue hours ago, but something else you did manually prevented the fix from working.... :)
Things:
1. Networking issues
2. Permissions
3. Firewall
4. Filesystem mount type
5. UpdateMedia
Sounds like your networking is OK, but even relatively minor or intermittent issues could cause problems. You could try attaching (temporarily of course) your PC directly to the core with a cross over cable (modern NICs usually don't even need that) to eliminate cabling and switching. And try fixing your NICs rather than autonegotiating - use sudo ethtool eth0 and 1 on the Core and properties of the adaptor in Windows to check what they are set to. Fixing to 100Full to start with. If either say half-duplex then you definitely have an autoneg problem. BTW - some NICs have been seen to have comms probs at Gb on LMCE, so 100Full again would help you eliminate that possibility.
Make sure that your Windows firewall is completely disabled whilst testing to eliminate that. Once the share(s) have been detected and added, from KDE desktop Dolphin file manager navigate to /home/data/public/Windows... blah blah, and see if KDE can browse your Windows folders and play files in Kaffine or Amarok - this will confirm basic connectivity. Copying large files back and forth can confirm you are getting the correct bandwidth as speed and duplex problems often cause massive reductions in bandwidth, especially only in one direction....
If you can't navigate/play - try enabling security logging on Windows in admin tools-local security policy then check the events in the Security Event log to confirm that LMCE is successfully authenticating. You should also look under shares/sessions in Computer Management, and keep hitting refresh. You should see LMCE periodically connecting to the share(s), especially just after it sets them up.
When it discovers the shares, use the option to accept the LMCE folder structure. And check that it creates public/data/audio|video|documents|pictures under the share - this will confirm application layer connectivity and write access. This is the best option to use anyway, and once the folders are there, you move your media into the appropriate ones so that it can discover them and add them to the library.
Be aware that the initial run of UpdateMedia will take a few minutes to populate your media library even when there are only a few media files, but much longer when there are a lot. Don't run UpdateMedia from the command line unless you know what you are doing. And don't forget to Reload the DCERouter after it has discovered and added all your shares.
Go to the admin web site, login and go to Media File Sync in the Media and Files menu. You should see your Windows shares under there when you navigate down on the left hand panel. Go into one of your media shares so that you can see your own folders/files - now choose the resync option. This will run UpdateMedia for you properly.
Pay close attention to the log window that opens. The first part of the run will identify the media files and attempt to generate/download metadata for them - if you see this happening against specific media files on your PC then at least you know it is able to see them. However, the second part of the run it is determining whether the media is "available" or "online". It may sound obvious that they are, but UpdateMedia can make a mistake here in some circumstances (I had this problem for 4 weeks before I finally worked it out!) If it lists all your files but says that the device is offline, skipping file. Then you have the CIFS/SMBFS issue I had. Go to the devices tree and navigate down to the share - you will find a data attribute in the definition that is called filesystem type - set to "cifs", change that to "smbfs".
Only once UpdateMedia has successfully run, you see the media mentioned in its log window, it doesn't declare the device offline, and the DB sync happens at the end, will you be able to see your media in LMCE.
Sorry, this was a brain dump, and thus not in a good order for troubleshooting, so I recommend you read it all first then go through it in a more logical order. Don't just follow it step by step, as I back track in spots!
HTH
QuoteSounds like your networking is OK, but even relatively minor or intermittent issues could cause problems. You could try attaching (temporarily of course) your PC directly to the core with a cross over cable (modern NICs usually don't even need that) to eliminate cabling and switching. And try fixing your NICs rather than autonegotiating - use sudo ethtool eth0 and 1 on the Core and properties of the adaptor in Windows to check what they are set to. Fixing to 100Full to start with. If either say half-duplex then you definitely have an autoneg problem. BTW - some NICs have been seen to have comms probs at Gb on LMCE, so 100Full again would help you eliminate that possibility.
The network environment i'm using, has been used with the same configuration for quite some time, there is no question my network settings, configuration, layout, etc... is ok.
QuoteMake sure that your Windows firewall is completely disabled whilst testing to eliminate that. Once the share(s) have been detected and added, from KDE desktop Dolphin file manager navigate to /home/data/public/Windows... blah blah, and see if KDE can browse your Windows folders and play files in Kaffine or Amarok - this will confirm basic connectivity. Copying large files back and forth can confirm you are getting the correct bandwidth as speed and duplex problems often cause massive reductions in bandwidth, especially only in one direction....
Always the first thing I do when I install a windows box... firewall = off, reportingmethod = none, etc...
I think i confirmed basic connectivity when I manually mounted my windows share on linux mce using smbmount. Also I can play the movies off my windows share through mce, after I mounted it manually in /home/public/data/other/test.
I can also see the mce box connecting to my windows share using the "shared folders" snap-in for the management console. Also see successful login under security audit.
QuoteIf you can't navigate/play - try enabling security logging on Windows in admin tools-local security policy then check the events in the Security Event log to confirm that LMCE is successfully authenticating. You should also look under shares/sessions in Computer Management, and keep hitting refresh. You should see LMCE periodically connecting to the share(s), especially just after it sets them up.
got it
QuoteBe aware that the initial run of UpdateMedia will take a few minutes to populate your media library even when there are only a few media files, but much longer when there are a lot. Don't run UpdateMedia from the command line unless you know what you are doing. And don't forget to Reload the DCERouter after it has discovered and added all your shares.
I checked the mount point... it's empty. Every configuration pattern i've tried.
Windows logs a successful auth.
Windows shows user logged into share.
but /mnt/device remains empty.
QuoteGo to the admin web site, login and go to Media File Sync in the Media and Files menu. You should see your Windows shares under there when you navigate down on the left hand panel. Go into one of your media shares so that you can see your own folders/files - now choose the resync option. This will run UpdateMedia for you properly.
Yes i've done this also, again something I read during my research... problem is, those windows shares we see listed there? They are symbolic links to the actual mount point of the share? Something eg: /mnt/device/33.... it's empty. there is no /mnt/device/33. It stops at /mnt/device.
QuoteThen you have the CIFS/SMBFS issue I had. Go to the devices tree and navigate down to the share - you will find a data attribute in the definition that is called filesystem type - set to "cifs", change that to "smbfs".
This is the juicy part... I actually saw a topic about this, and when I saw it, I was convinced this would be my problem. I tried that, I also tried changing that setting in the config file. To no avail. I wasn't exactly sure how long it would take for the core to pick up the change and restart the associated service so I rebooted to make sure the change was in effect. Still got errors in updatemedia, and /mnt/device was still blank.. no mounted shares... Where can I look to try and observe the error messages generated by mce's mounting mechanism?
I'm leaning toward this mounting issue with the difference between cifs/smbfs... i'm sure thats it, because if I try mounting using -t cifs in my mount command, I get some obscure error, I have to use -t smbfs and it'll mount find... but thats just manually, and as I stated before, I changed the mounting method but it still wouldn't mount. I think if we can just find where that mechanism is logging errors... I know it's autofs, but I see no errors being generated in the typical log files...
The only thing I haven't looked at in depth are the security logs in windows. At first glance everything seems to auth just fine on windows side, then nothing else happens. I haven't turned up my logging level yet, i'm going to try this next time I re-install linuxmce and it goes through all it's wizardry and tries to connect to the shares again.
EDIT: I decicded to move on and try to get the RAID working and give the shares a rest... I noticed this in my syslog
Feb 11 00:54:36 dcerouter automount[15507]: mount(generic): failed to mount /dev/md3 (type auto) on /mnt/device/28
Feb 11 00:54:36 dcerouter automount[15507]: failed to mount /mnt/device/28
Feb 11 00:54:36 dcerouter automount[15541]: >> mount: you must specify the filesystem type
Feb 11 00:54:36 dcerouter automount[15541]: mount(generic): failed to mount /dev/md3 (type auto) on /mnt/device/28
Feb 11 00:54:36 dcerouter automount[15541]: failed to mount /mnt/device/28
so I know auotofs is logging to syslog, now why don't I get any errors when configuring the windows shares...
well, now i'm back on troubleshooting shares i've been inspired...
First, I'm going to suggest verifying that there are no other DHCP servers active in you internal network. I had fun after resetting my linksys wireless router and not thinking that resetting it re-enabled the DHCP server. A quick check is to run ipconfig on your windoze box and verify the IP address is 192.168.80.x
Second, I'm going to reiterate Collin's suggestion to minimize/change you network. I thought my network was working fine, but in reality one of my problems was that my Netgear GS105 was bad. Here's what my network looked like (abridged):
ISP -> Linksys BEFSR41 -> Core/hybrid -> Netgear GS105 -> PS3, Dlink DGS2208 -> kubuntu, Dlink DBS2208 -> gentoo
The gentoo & kubuntu systems were working great. Could NFS to each other at 36MB/s.
The Core/hybrid could not reliably NFS to either the gentoo or kubuntu boxes.
For a test I removed the Netgear & PS3 from the network:
ISP -> Linksys BEFSR41 -> Core/hybrid -> Dlink DGS2208 -> kubuntu, Dlink DBS2208 -> gentoo
Poof, NFS started working great at 36MB/s between core/hybrid and kubuntu. I then put the netgear back in and tried different cables. No joy. This isolated the problem to the netgear switch.
Originally I had tried samba on the kubuntu system, but couldn't get it working so switched to NFS (I'm much more comfortable in *nix land than windoze). In retrospec the bad switch was probably my problem when I tried samba/cifs.
HTH,
Roy
orionsune - not sure whether you mean that you have had LMCE and the network working in this config for quite a while, or JUST the hardware components. Certainly your post suggests that either your LMCE is new or has never worked for shares. So if you mean just the hardware, not LMCE - please don't dismiss the suggestions, just having the hardware (PCs, cables, switches) working under a different OS means nothing. It has everything to do with your NIC drivers - if your LMCE is new, then this component (arguably the most significant and prone) is completely new and you have never had it working before, in effect....
I don't think I have any more suggestions for you until you have rebuilt as there is no way to know what state your system is in after the mounting you have done.
I agree that there seems to be a mounting issue - that seems obvious from your last post. But I am questioning now whether it has anything to do with the cifs/smbfs issue that I have described (it sounds like you have been reading my posts on the issue). My issue did not involve the share being missing from /dev/mnt.... this was fine, as was the symlink. As I say I could browse the media from the symlink, no problem, cd into the /dev/mnt, etc... the mount was fine, and UpdateMedia could see the attributes, new files, etc. Just thought they were offline when it checked using cifs. The mounting is obviously not that straightforward. Even though it is mounting, something else is going on to confirm this. Otherwise you would be able to search for media and play it in LMCE like I could, even though it doesn't appear in the media browser.
Good luck
So I just tried you guy's suggestion despite my stubbornness...
I connect my network share pc (windows box) to the internal nic of the lmce box using a crossover cable. Then the cablemodem connected directly to the external nic of my lmce box. Completely isolating the lmce box and windows box from my existing network. No change...
Although I have had another development... i've finally gotten logging to log the errors during automount and here they are.
Feb 11 01:06:55 dcerouter kernel: [ 939.815214] CIFS VFS: cifs_mount failed w/return code = -13
Feb 11 01:06:56 dcerouter kernel: [ 940.312890] CIFS VFS: Send error in SessSetup = -13
Feb 11 01:06:56 dcerouter kernel: [ 940.387544] CIFS VFS: cifs_mount failed w/return code = -13
Feb 11 01:06:57 dcerouter kernel: [ 940.979295] CIFS VFS: Send error in SessSetup = -13
Feb 11 01:07:22 dcerouter automount[31586]: parse(sun): entry 36 is empty!
Feb 11 01:07:22 dcerouter automount[31586]: failed to mount /mnt/device/36
Feb 11 01:07:23 dcerouter automount[31868]: parse(sun): entry 37 is empty!
Feb 11 01:07:23 dcerouter automount[31868]: failed to mount /mnt/device/37
So it's obviously the cifs/smbfs issue, but i've put "smbfs" in the filesystem field and no change it still gives CIFS errors and mounting errors. I even tried modifying the automount map file and hardcoded the option to use "-fstype=smbfs" instead of allowing it to use a variable. Still I can mount all these shares manually...
Thanks for trying tho guys, at least I know it's something to do with the mounting procedure... if I find a solution i'll be sure to post details.
EDIT: I was hoping one of you guys would recognize those errors. It seems to me, everything is pointing to the cifs/smbfs issue, but when I put smbfs in the filesystem field of the share through the web admin, and restart/reboot/powerdownbackup, I still recieve the same error, and shares still do not get mounted. Actually I found out if you try to cd into /mnt/device/##, then the autofs attempts to mount the filesystem associated with the number. I used this method to generate those error messages, but they are generated the same by itself also. I don't understand on the Windows side, the only log entry being recorded is a successful login from the username I specified linuxmce to use for the share.
BTW: I tried seting up a NFS share on my spare *nix box, I don't know if it's my configuration yet, but it wasn't detected at all. I do admit, i've never really used NFS much because of permission issues in the applications I used in the past.
EDIT2: It dawned on me to try and mount manually using cifs... so I did, and i cant mount my windows shares manually using smbfs or cifs, so again, whats with the mounting errors? errrr
Oh My God... yes I had to spell it out. I want to give each of you guys my home address and directions. I would like for everyone that tried to help, come to where I live and put a foot in my ass.
Out of pure and total desperation last night, I checked my windows firewall and it was ON! I sware to god and all that is holy and righteous that I turned that damned firewall off when I installed windows. I just installed windows not only a few days ago, because I went from XP to Vista. I decided to see what Vista is all about. Well, this is my second installation of Vista, and I have to admit, the first time I installed Vista, I remember having this firewall problem with another technology I was researching. The problem was, I swore that I turned the firewall off after installing windows, then when nothing worked right over my network, I checked the firewall settings and it was back on. I think windows Vista is turning the firewall back on by itself, I sware it has to be because i've never in my life had any kind of memory problems like this. And twice i've sworn I turned the firewall off, I go back and check and it's back on.
Now.. I turned the firewall off, but I had already broken the autofs mechanism in mce during my troubleshooting, so I need to re-install mce again and test it's "out of the box" share discovery and autofs again. I hope it will work this time. But I am still skeptical. I am a firm skeptic because even with windows firewall being on that whole time, I was able to mount my windows shares manually using both smbfs and cifs. And windows was logging in the event log, successful logins from the autofs attempting to mount the shares. If windows firewall was preventing autofs from mounting my shares, then shouldn't it prevent me from manually mounting them as well? I will admit, I do not claim to know all the intricacies and obscure methods used in network protocols, maybe there is something different autofs does that gets blocked by windows firewall where manually mounting does not use. Who knows... (the RFC knows...)
Anyways, I will re-install mce on my box and re-test this again with windows firewall OFF and post my results.
I would appreciate any flaming please. A foot in the ass, a couple variations of the spelling newbie... anything please lol.
Have you tried accessing the contents of the files as well besides just mounting the shares?
Just a thought - I noticed somewhere in some script a ping test (not the one to google) and I think I was looking at storage device scripts at the time. It is just possible that one of the things used to test share availability is ping. If so, it is also just possible that your Windows firewall was configured to allow file sharing (inbound), but probably not ICMP/ping. If so, then it would have thought the share/server was offline even though you manually mount.
Have fun!
Negative houston... I just got home, re-installed MCE fresh... made damned sure windows firewall is off, same identical results. Once again, here are my log entries. Too bad I can't find what code -13 means.
I get this during LinuxMCE's automatic detection wizard...
Feb 12 18:51:15 dcerouter kernel: [ 1582.854473] CIFS VFS: Send error in SessSetup = -13
Feb 12 18:51:15 dcerouter kernel: [ 1583.095652] CIFS VFS: cifs_mount failed w/return code = -13
Feb 12 18:51:16 dcerouter kernel: [ 1584.962725] CIFS VFS: Send error in SessSetup = -13
Feb 12 18:51:17 dcerouter kernel: [ 1585.204772] CIFS VFS: cifs_mount failed w/return code = -13
Feb 12 18:51:17 dcerouter kernel: [ 1586.671798] CIFS VFS: Send error in SessSetup = -13
Feb 12 18:51:18 dcerouter kernel: [ 1586.939598] CIFS VFS: cifs_mount failed w/return code = -13
Feb 12 18:51:18 dcerouter kernel: [ 1588.550243] CIFS VFS: Send error in SessSetup = -13
Feb 12 18:51:19 dcerouter kernel: [ 1588.797034] CIFS VFS: cifs_mount failed w/return code = -13
Directly afterwards, and everytime I try to cd into my /mnt/devices/## folder where the mount point is, I recieve these errors.
Feb 12 18:52:31 dcerouter automount[28724]: failed to mount /mnt/device/28
Feb 12 18:52:31 dcerouter automount[28845]: parse(sun): entry 35 is empty!
What is interesting here, I didn't notice before, is that the first set of errors only happen when the auto wizard detects my windows shares. The following errors are the only ones I see after the wizard is finished.
QuoteHave you tried accessing the contents of the files as well besides just mounting the shares?
Yes, actually if I mount my windows share somewhere inside LinuxMCE's /home/public/data , it sees all my media and I can play it just fine.
QuoteJust a thought - I noticed somewhere in some script a ping test (not the one to google) and I think I was looking at storage device scripts at the time. It is just possible that one of the things used to test share availability is ping. If so, it is also just possible that your Windows firewall was configured to allow file sharing (inbound), but probably not ICMP/ping. If so, then it would have thought the share/server was offline even though you manually mount.
That actually could make a whole lot of sense, except I remember reading also that it doesn't bother attempting to mount those shares if it doesn't recieve a ping reply. I have a log file full of autofs trying to mount those shares every 5 minutes or so on it's own.
I am so frustrated, this is garbage. I have a question, you guys have this working just fine? Can I look at your autofs map file (/etc/auto.PlutoStorageDevices, network configuration, flavor of windows (xp/vista)? I just don't get it. This copy of windows vista is only 5 days old, I have no exotic configurations on my network or pc. I have a pretty standard setup, have tried to match all the hardware i've collected to the list of known compatible hardware in LinuxMCE.
Well I am back to troubleshooting, think i'll try and get more detail out of the windows side as it tries to mount. Screw windows event log, time to download ethereal. I'll update later... thx everyone for your input...
Sorry, just blew up my installation! Will be re-installing and reconfiguring for a while...
Well, I have finished analyzing my network traffic using wireshark.
When I mount the share manually using mount or smbmount, there are tons of browser/smb/cifs traffic showing up.
When I allow linuxmce to attemp an aoutmount of those shares (while monitoring both ends of traffic), a ping is sent to my windows share box, and a replay is recieved by the linuxmce box, but then nothing else happens. It just pings my windows box, and generates an error in the syslog. The linuxmce box never even attempts through out any browser traffic after pinging and recieving a response. This sounds like coolinjones's hunch, but... I commented out the pinging mechanism in the autofs map file so that it would bypass pinging and go straight to the mount command, no luck... same error logged in syslog also...
Very strange - don't think I can help any further. I was going to say, make sure that the ICMP coming back is an echo_reply, not an expiry/destination unreachable/source_quench, but if the commenting made no difference.... I can only assume that some other logic mechanism somewhere else has already marked the share as down (even though the server may be marked as up confirmed by the ping) and so it doesn't even try. BTW, in the admin site for the share, at the bottom of the details section there is a tick box that indicates whether the share is "online", is that ticked? Mine wasn't, I could turn it on, but it would go off again after a few seconds. Sorry, I've forgotten, did the pnp even detect the share and create a device that isn't working?
Anyway, persevere - took me a month to get mine online :)
Yes, it detects the shares and the wizard runs... the online box is checked...
At least i'm homing in on the source, i'm alot closer than I was a day ago. I've narrowed it down to the autofs mechanism. I've been playing with the syntax in the map file for mounting shares. The autofs mechanism mounts my raid fine, so I haven't ruled out that something between linuxmce and the windows box is causing a problem. But like I said, there is absolutely no browser traffic making it to the windows box, as if the automount command is never being executed. Even though I don't really NEED this work i'm stuck on it now, I won't rest until I solve this.
UPDATE:
I tested to see if everything was being pulled from the database properly, using a method mentioned previously..
Quote
you can test the code by running the following:
sudo /etc/auto.PlutoStorageDevices 91
( please change 91 to the device Number of your Storage Device)
Everything was returned accurate.... so thats not it...
omg i just tried it with a windows xp box and it works!
I didn't have an xp box to try before now, use a friends laptop with xp on it.
so i'm looking into windows vista's security policy now... because we know windows firewall is off and whatnot...
what's strange, is i'm using wireshark for windows... and wireshark shows absolutely no browser traffic whatsoever, not even blocked traffic...
Just had a thought. You may need to specify the workgroup for the mount. I found this hint in:
http://www.informit.com/articles/article.aspx?p=1165037 (http://www.informit.com/articles/article.aspx?p=1165037)
I think to do this you may need to modify the mount options in /etc/auto.PlutoStorageDevices to include a
domain=yourvistaworkgroup
Look around line 171, you should see:
## Do the mount
if [[ "$Username" == "" || "$Username" == "guest" ]] ;then
echo "-fstype=$CIFS_FileSystem,username=guest,guest,dir_mode=0777,file_mode=0777$CIFS_ExtraOpts ://${IPaddress}/${Share}"
else
echo "-fstype=$CIFS_FileSystem,username=$Username,password=$Password,dir_mode=0777,file_mode=0777$CIFS_ExtraOpts ://${IPaddress}/${Share}"
fi
add "domian=whatever" to both of the -fstype rvalues.
FYI, it looks these are the default domains:
XP = MSHOME
Vista = WORKGROUP
LinuxMCE = LinuxMCE
Also from reading on ubuntu forums, it looks like it is required to have a username and password when mounting vista shares.
I don't have any windoze boxes running so can't test this.
HTH,
Roy
I have to use a username and password even for my XP box although the share is open access...
Wonder if Vista is enforcing SMB signing?
Coolinjones,
It's funny I am wondering the same exact thing. As I was navigating through vista's plethora of security policies, I found in the network sharing control panel that "Password Protected File Sharing" was turned off. In essence, making it an open share as you said. With that in mind, I wonder is because linuxmce is specifying a username and password that vista is rejecting it. I went to turn "Password Protected File Sharing" on, and test it again... but I had already broken my LinuxMCE box, so I have to re-install again tonite to test this. I really need to just install vmware for all this testing and keep a copy of the image with a clean install.
BTW: I had previously enabled LM, NTLM and NTLM2 to get windows working with a different linux box so I know that wasn't an issue. It's funny how microsoft shipped vista with ONLY NTLM2 enabled and LM, NTLM rejected by default. As if they are imposing their so called wanna-be standards on us. LOL on mr gates....
Royw,
I am going to try that too, I would never have thought of that, i've used linux products for over 13 years and never had to do that with previous version of windows. Leave it to mr gates to screw all of us up... It seems from all this troubleshooting... that my problem is all mr gates fault. Why do I suddenly have an urge to strangle someone with the name Bill.
BTW: I changed the workgroup of all my windows boxes to "LinuxMCE" for consistancy.
Again, thanx guys, I think we are getting close... I can't wait to get home and try this, especially considering my video capture card AND my gryo mouse came in the mail today. Woohoo....
in case my comments were not well outlined... my username/password suggestion and SMB signing are completely different issues. SMB signing is usually only something that gets turned on on a corporate network (by default from XP SP2 onwards), but I suppose it is something that could be turned on on a home XP machine if it is professional, but it seems unlikely that you could have done it by accident (unless the PC was originally on a corporate network of course) Just a thought.
I think that username/password should be the focus.... I created an account on my XP machine (user only, not admin), then entered the username and password into the correct fields in both the server device and the share device.
Ok, it works now... this is what happened.
I recieved my capture card and remote in the mail yesterday, so I was ready to go into production with the box. I added the hardware, and re-ran the wizard. It picked everything up, I chose to use MythTV as my PVR software... then when I tried to watch TV, it said "Cannot play this media"... so I said screw it, and decided to do one more re-install now that i've collected the last bit of hardware I plan on using in this box...
Now, with that said, I re-installed and accidentally chose the UI mode 1 with no 3d effects. No big deal, i'll change it on next reboot right? Ok, so the AV wizard finished, the core/md start up and present me with the second wizard that configured all my devices for me... As I begin to go through this wizard, LinuxMCE detects my windows box as usual... and I proceed as usual. Except there is something different here...
Previously... when I chose UI mode 3... and the second wizard fires up... and it see's my windows box... and it asks me for the username/password for the windows box... then the subsequent shares it detects after that never ask me for a username and password... I assume this is because I supplied it for the main device (windows box)...
Currently when I chose UI mode 1... and the second wizard fires up.... and it see's my windows box... it DOES NOT ask me for a username/password for the main device (windows box) instead... when it starts to see the subsequent shares, it asks me a username/password for each individual share on the windows box. This is different than when I chose UI mode 3.
Now at this point I ask myself... "Is choosing the different UI mode really affecting the way it's detecting my shares and asking for input?" I was very skeptical, it had to be something else I did different. So, I decided to re-install AGAIN this time choosing UI mode 3, and I recorded every single step all the way to getting a drink, and using the bathroom.... Guess what... it asks me for username/password for the file server/main device/windows box and not the subsequent shares it detects... I allow the wizard to finish and check the shares, and they are NOT mounting...
Now.. again, I re-install AGAIN... this time choosing UI mode 1... and sure enough, it DOES NOT ask me for username/password when configuring the file server/main device/windows box but instead asks me for a username/password for each subesquent share detected thereafter.
Ok, so I allow everything to finish, the shares are mounted properly and all my media is there. So at this point I am not looking to see what is different than before. This is what was different.
In the Admin Website...
On the top menu bar...
Advanced -> Configuration -> Devices
On the left device list.
CORE -> Windows Box
at the bottom where the two fields are labeled username/password. My previous installation where I was choosing UI mode 3... these boxes were filled out with my username/password. Obviously because the wizard asked me for the username/password when it detected the windows box(parent device)...
On the installation where I chose UI mode 1... these fields were blank. Obviously because it did not ask me for a username/password when detecting the parent device (windows box).
CORE -> Windows Box -> Shares
at the bottom where the two fields are labaled username/password. My previous installation where I was choosing UI mode 3... these boxes were blank. Obviously because it is supposed to retrieve the username/password for mounting from the parent device.
On the installation where I chose UI mode 1... these fields were filled out with my username/password. Obviously because it asked me for a username/password for each individual share it detected.
So... to sum it up... place username/password in the individual child devices (shares) instead of the parent device. This seems to only be true for windows vista boxes, as when I connect my wife's laptop running windows XP, it works with both methods...
After properly mounting my shares and cataloging all the information, I was able to switch back to UI mode 3 and everything is fine. It was simply a mis-configuration of the parent/child devices. I attribute this bug to Microslop Winblowz...
But, as we all know, things are always too good to be true. Since I made it past this milestone, I went to set my raid up again. When I drop to command prompt to partition and format my 3 250gb drives for the raid, it gives me an error about /dev/hdb and /dev/hdc being in use and I cannot format them. But I can most definately partition them, and write the table, just no format. I checked to see if they are mounted, they are not. Now when I partition and format my /dev/hdd, it works freaking great... wtf man... anyways, my solution to this is probably remove the drives, boot completely up, shut back down, add the drives, and try again.
but when I am worried about, is that I previously had these drives in a raid... but now i'm prepared to wipe them and start over.. I suspect the previous raid has written some kind of information to the boot record, or tables, and when I attemp a format, it sees this and halts. The reason I suspect this, is when I try to run fsck on them, to check for errors, it says this...
fsck 1.40.2 (12-Jul-2007)
fsck: fsck.mdraid: not found
fsck: Error 2 while executing fsck.mdraid for /dev/hdb1
But I just deleted, and recreated a partition... wtf is it talking about fsck.mdraid?! Well, like I said, it must still think it's in a raid... the admin web panel does not show any raids detected. So I guess i'll be playing with the command line raid utility... only problem is i've never used the mdadm utilities, i've already used the raidtools utilities... so looks like i'm doing some more research..
Thanks everyone for all the suggestions... you guys are freaking awesome...
Just FYI: since i mentioned having problems with my raid...
The superblocks on the drive still had existing raid info in it. I did a mdadm -examine and found out it thought it was still part of /dev/md4 so I did a mdadm manage /dev/m4 --stop then i did a mdadm --zero-superblock /dev/hd## on each device... solved the problem.
I couldn't tell you the exact commands without actually doing it myself, but you're on the right track using mdadm at the command line. You're correct about there being extra data written on the drive and will have to delete each raid partition using mdadm. I think it's something like:
mdadm --stop /dev/md0 to stop the array
mdadm --remove /dev/md0 /dev/sda1
mdadm --remove /dev/md0 /dev/sdb1
mdadm --zero-superblock /dev/sda1
mdadm --zero-superblock /dev/sdb1
I've run into this before and after a little googling usually don't have a problem fixing it. I think things have to be done in a specific order is the hardest part. Hope this helps. -Ruben
Fantastic! Congratulations!
This should be entered into Mantis as an issue.
I haven't done RAID yet so can't help there...
Have fun,
Roy
QuoteI've run into this before and after a little googling usually don't have a problem fixing it. I think things have to be done in a specific order is the hardest part. Hope this helps. -Ruben
Yep, I did a little googling and managed to figure it out, it was exactly as you said...
Otherwise, all issues I had are now solved, thank you everyone... awesome community...
orionsune - as Roy says, you should log the results of your troubleshooting in a Mantis ticket for the different UI behaviours so that it gets fixed up for next time. Go to http://mantis.linuxmce.org create an account and log it under the right project as a minor bug.
Col
guys - I will do that... thanks...
Quote from: orionsune on February 15, 2008, 08:50:32 PM
Ok, it works now... this is what happened.
I recieved my capture card and remote in the mail yesterday, so I was ready to go into production with the box. I added the hardware, and re-ran the wizard. It picked everything up, I chose to use MythTV as my PVR software... then when I tried to watch TV, it said "Cannot play this media"... so I said screw it, and decided to do one more re-install now that i've collected the last bit of hardware I plan on using in this box...
Now, with that said, I re-installed and accidentally chose the UI mode 1 with no 3d effects. No big deal, i'll change it on next reboot right? Ok, so the AV wizard finished, the core/md start up and present me with the second wizard that configured all my devices for me... As I begin to go through this wizard, LinuxMCE detects my windows box as usual... and I proceed as usual. Except there is something different here...
Previously... when I chose UI mode 3... and the second wizard fires up... and it see's my windows box... and it asks me for the username/password for the windows box... then the subsequent shares it detects after that never ask me for a username and password... I assume this is because I supplied it for the main device (windows box)...
Currently when I chose UI mode 1... and the second wizard fires up.... and it see's my windows box... it DOES NOT ask me for a username/password for the main device (windows box) instead... when it starts to see the subsequent shares, it asks me a username/password for each individual share on the windows box. This is different than when I chose UI mode 3.
Now at this point I ask myself... "Is choosing the different UI mode really affecting the way it's detecting my shares and asking for input?" I was very skeptical, it had to be something else I did different. So, I decided to re-install AGAIN this time choosing UI mode 3, and I recorded every single step all the way to getting a drink, and using the bathroom.... Guess what... it asks me for username/password for the file server/main device/windows box and not the subsequent shares it detects... I allow the wizard to finish and check the shares, and they are NOT mounting...
Now.. again, I re-install AGAIN... this time choosing UI mode 1... and sure enough, it DOES NOT ask me for username/password when configuring the file server/main device/windows box but instead asks me for a username/password for each subesquent share detected thereafter.
Ok, so I allow everything to finish, the shares are mounted properly and all my media is there. So at this point I am not looking to see what is different than before. This is what was different.
In the Admin Website...
On the top menu bar...
Advanced -> Configuration -> Devices
On the left device list.
CORE -> Windows Box
at the bottom where the two fields are labeled username/password. My previous installation where I was choosing UI mode 3... these boxes were filled out with my username/password. Obviously because the wizard asked me for the username/password when it detected the windows box(parent device)...
On the installation where I chose UI mode 1... these fields were blank. Obviously because it did not ask me for a username/password when detecting the parent device (windows box).
CORE -> Windows Box -> Shares
at the bottom where the two fields are labaled username/password. My previous installation where I was choosing UI mode 3... these boxes were blank. Obviously because it is supposed to retrieve the username/password for mounting from the parent device.
On the installation where I chose UI mode 1... these fields were filled out with my username/password. Obviously because it asked me for a username/password for each individual share it detected.
So... to sum it up... place username/password in the individual child devices (shares) instead of the parent device. This seems to only be true for windows vista boxes, as when I connect my wife's laptop running windows XP, it works with both methods...
After properly mounting my shares and cataloging all the information, I was able to switch back to UI mode 3 and everything is fine. It was simply a mis-configuration of the parent/child devices. I attribute this bug to Microslop Winblowz...
Hi orionsune,
Could you Mantis this difference between the way the autodetection scripts handle adding shares under UI1 & UI2 please so that its looked at asap.
Thanks
Andrew
Yes, I plan on it. Thanks..