Posts filed under 'computers'
It’s frustrating when things don’t work as they should. While setting up a Samba server on SuSE 11, I had the pleasure of troubleshooting why permissions weren’t being inherited by children of a folder. I had what seemed like all of the appropriate settings in my smb.conf file. I looked over it a million times. inherit acls, inherit permissions, blah blah blah. It still wasn’t working and I had no idea why. New files COPIED the parent permissions but they weren’t INHERITED. In the Advanced Permissions dialog, the files all said “Inherited From: None” so I knew inheritance wasn’t working. After lots and lots of Googling, I saw someone suggest setting the vfs objects property. After I did that, everything worked! So here are some tips on getting permission inheritance working:
In your /etc/fstab, make sure you have the acl and user_xattrib mount options set for the partition that contains the files you are serving:
/dev/sda2 /local reiserfs acl,user_xattr 1 2
In your /etc/samba/smb.conf, make sure you have all the inherit options set to yes and the vfs objects option set:
inherit acls = yes
inherit owner = yes
inherit permissions = yes
vfs objects = acl_xattr
map acl inherit = yes
Keywords: samba 3.4.x suse sles 11 permissions inherit inheritance acls smb.conf smb
February 16th, 2011 at 10:48am
April 7th, 2009 at 04:01pm
April 7th, 2009 at 04:01pm
no sound (dell precision m70, laptops, etc)
http://www.kellys-korner-xp.com/top10faqs.htm #6
http://www.kellys-korner-xp.com/xp_tweaks.htm #371
April 7th, 2009 at 04:01pm
Can’t connect to winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv
stop “windows management instrumentation” service, rename “%windir%\system32\wbem\repository”, start service
http://www.microsoft.com/technet/scriptcenter/topics/help/wmi.mspx#EQKAC
April 7th, 2009 at 04:01pm
system event logs were set to read only
April 7th, 2009 at 04:01pm
So continuing with my Visual Studio 2008 installs (and how horrible the installation procedure is), I had a system that ran the Service Pack 1 install and seemed to hang at the end. Normally, I just schedule the install and let it do its thing with unattended setups and an auto-reboot at the end. I got a call from the user saying the SP1 was still installing and this was 5 hours later. I know the SP1 install takes forever, but 5 hours was a little much. So I tried to cancel the install but no luck, so I had to end task SPInstaller.exe.
Off to the log files I go. Wait a minute…the SP1 log file is 5GB! What’s going on?! I wasn’t about to open such a huge file so I deleted all the log files and re-ran the install in non-unattended mode. Shortly after starting the install, it failed with an “Installation suspended, incomplete” message. I thought this meant something but in the end, all it means is that a previous install failed and it rolled some stuff back.
So I ran the install again and this time, it went further, like normal. I noticed on other systems the log file would only grow to 20-30MB so I waited until the log file grew to about 50MB and then end tasked the installer again. I opened up the log file and the end was filled with this message over and over:
Warning 1909. Could not create Shortcut Visual Studio 2008 Command Prompt.lnk. Verify that the destination folder exists and that you can access it.
Why couldn’t it create the shortcut? Who knows? Google, probably. I just searched for “warning 1909″ and saw a bunch of stuff about the Office installer failing with this message. None of the fixes seemed to apply to me. I checked the permissions at C:\Documents and Settings\All Users\Start Menu\Programs and everything seemed good. The VS2008 program folder existed and permissions were also normal.
Well, long story short, this forum thread helped me resolve my issue (I guess this problem also occurs with VS2005). It was on the second page of my search and it’s weird that if I had searched for my message with quotes around certain parts, this result would’ve been hidden by Google.
Anyway, I looked at the system environment variables to see if the ComSpec variable was set incorrectly. And it sure was. It was…missing. Argh, why did the user do that for?! I recreated the ComSpec variable and set it to %SystemRoot%\system32\cmd.exe and re-ran the installer. Everything worked after that. I guess the installer uses that environment variable to determine how to create that command prompt shortcut.
December 4th, 2008 at 12:28pm
So I’m running the Visual Studio 2008 install on a system the other day and it’s failing. Long story but we’re installing the .NET Framework 2.0 SP1 redistributable first to avoid the automatic reboot with the unattended VS2008 install. So the .NET install runs in unattended mode and near the end, it gives an error:
Error 25015.Failed to install assembly ‘C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.EnterpriseServices.dll’ because of system error: Access is denied.
I checked that the file existed and the permissions were normal. I looked at the log files and couldn’t find anything useful. I installed a file unlocking program to see if the file was in use and needed to be unlocked but it was never in use. I ran Filemon and Regmon to see if I could notice any weird behavior but I didn’t recognize anything out of the ordinary.
I turned to Google for some quick solution but didn’t find anything so I thought the next best thing to do would be to uninstall the existing .NET Framework 2.0 installation. Sure it gave me a warning that things would stop working (like the user’s install of VS2005!) but that was a risk I was willing to take to get this over with.
So I uninstalled the base 2.0 installation and then tried to run the SP1 install again. Same deal. So I ran the base 2.0 install to see if that would work. Nope. Same error.
So back to Google I went. Googling for ‘error 25015′ returned a bunch of proposed solutions. There was never a solution to the exact error message that I had but I was willing to try anything. With each one that I discovered, I thought I had found the solution. I’ll consolidate them here with some comments on how they worked for me.
- The first things I tried were what was suggested in Aaron Stebner’s blog since these MSDN guys always have the answers to Visual Studio related issues.
- I ran the guy’s SubInAcl script, which seemed like a good idea. Reset all the permissions on the important registry keys and system folders. Perfect. Same error.
- So I ran the guy’s .NET Cleanup Utility, which seemed like a good idea. Clean up all the .NET files and registry keys that might be causing problems. Perfect. Same error. I ran the utility choosing just to clean up 2.0 and when that didn’t work, I ran it choosing to clean up all versions of the .NET Framework. Same error. I ended uninstalling .NET 1.0 and 1.1 with no help.
The next things I tried were suggested in the MSDN forums.
- There were many success reports in this thread which involved deleting/renaming the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 folder. Tried that. Didn’t help.
- There were many success reports in this thread about delete/renaming/resetting permissions on the C:\Windows\Assembly folder. Tried that. Didn’t help.
- Finally, on the very last page of the Google results for social.msdn.microsoft.com, I found this thread about deleting/renaming the C:\Windows\WinSxS\Policies folder. I looked inside and at this point, I had already uninstalled VS2005 so I knew I could delete any of the folders that contained VS80 or VS90 (from VS2008) in them. I was liberal in my deleting and decided to delete matching folders one folder up (C:\Windows\WinSxS). Then I noticed a little folder by itself at the bottom of the list in the WinSxS folder. It contained “System.EnterpriseServices” in the name!!! Holy crap! DELETED! Ran the install again and voila! It worked! I never looked at what was inside that folder on this machine before deleting it but I guess there was a corrupt file in there or something.
Well, this basically took up my whole day because now I had to reinstall VS2005 and then go back to what I was originally doing, installing VS2008 + SP1 and we all know how long that takes. :sigh:
December 4th, 2008 at 11:58am
Ever since Microsoft began offering Virtual PC for free to download, a lot of users have been installing it to test out the usefulness of virtual machines. A couple laptop users complained that their machines would blue screen while starting up Windows with the wired network cable plugged in, although Windows would start up fine with the cable unplugged (which could then be plugged back in after login). I couldn’t figure it out but did narrow it down to Virtual PC 2004 being installed. I finally had the chance to work on one of these laptops for longer than five minutes and began my search on Google for the answer since I sure couldn’t do it myself.
All of my searches for a combination of the words “virtual pc ndis.sys blue screen driver_irql_not_less_or_equal” came up with irrelevant results. The only page that came close was this newsgroup post that suggested that there was a conflict between Virtual PC and the VPN client (Nortel Contivity VPN) installed on the laptop. So I went off searching for more details about the conflict and found this page that suggested uninstalling both Virtual PC and the VPN client, then reinstalling Virtual PC first before reinstalling the VPN client.
Well, first I uninstalled the VPN client and tested to see if the problem really went away. It did. I noticed that version 5.x of the client was installed so I tried installing 6.x. The problem came back. Uninstalled VPN, uninstalled Virtual PC, rebooted, reinstalled Virtual PC, rebooted, reinstalled VPN, rebooted, blue screen.
I decided to see why these two software would conflict. I went to Control Panel, Network Connections, opened the properties of the wired connection and examined the list of services and protocols enabled for the connection. The ones of note were the network filter services: Virtual Machine Network Services (from Virtual PC), Eacfilt (from VPN client), and Odyssey Network Services (from Funk Odyssey wireless client software). I unchecked the Virtual PC service from the adapter, rebooted, and everything was fine except that the adapter was no longer available for use within Virtual PC.
Back to the services list, I couldn’t uncheck the VPN service since the user would need it on this adapter but I wondered why the Odyssey service was enabled on the wired adapter. I rechecked the Virtual PC service and unchecked the wireless service. Rebooted and everything was fine! Checked to make sure Odyssey was working with the wireless adapter, checked to make sure Virtual PC worked with both adapters, and checked to make sure VPN worked with both adapters. Success!
Summary: If you’re getting the same type of blue screen from NDIS.SYS that I observed, check your list of services enabled for the wired adapter and disable any unnecessary services. Good luck!
January 5th, 2007 at 03:04pm
Wondering why your Y and Z keys are swapped in X? That’s probably because the keyboard layout is set to German (de) instead of English (us). Did you say you used SUSE AutoYaST and had it configured for the english-us keyboard mapping? Well, we had a couple of AutoYaST configuration files and the layout problem only occurred for a couple of them. I compared the XML files and noticed that in the keyboard section, the ones that didn’t work contained extra settings before the keymap setting (I didn’t make them!). I removed the entries and now the keyboard layout is set correctly!
I tried to search for the XML schema and was only able to find this one page with any useful information. Looking at it, we can see that the only setting that should be defined under the keyboard section is keymap. If there’s anything else in that section, the section is invalid and therefore skipped! I guess the default (alphabetically?) keymap setting is German (de), hence our problem. Here’s a little excerpt from an XML file to point out what to look for:
<?xml version="1.0"?>
<!DOCTYPE profile SYSTEM "/usr/share/autoinstall/dtd/profile.dtd">
<profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns">
<install>
...
<general>
...
<keyboard>
<keymap>english-us</keymap>
</keyboard>
<language>en_US</language>
...
There shouldn’t be anything in the keyboard section except for keymap. Anyway, if you don’t want to go through the trouble of reinstalling the OS, you can easily change the X keyboard layout (assuming you’re using Xfree86). At the shell, open up /etc/X11/XF86Config and look for the following lines. Make sure the XkbLayout setting is set to ‘us’. Then restart the X server by pressing Ctrl-Alt-Backspace.
Section "InputDevice"
Driver "Keyboard"
Identifier "Keyboard[0]"
Option "Protocol" "Standard"
Option "XkbLayout" "us"
Option "XkbModel" "pc104"
Option "XkbRules" "xfree86"
EndSection
February 16th, 2006 at 03:30pm
Previous Posts