Cannot Login to Remote Desktop With Correct Credentials

You are using Microsoft RDP and trying to connect to a remote machine. You enter the correct credentials but you cannot login. The message that you get is that the credentials are incorrect. While there could a litany of reasons why this is happening, but one more think you could check is the registry entry for the attribute LmCompatibility level at this location HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel. Try setting it to 5 which essentially sets NTLMv2 to security level 5. Retest your issue and it might just work.

Reclaiming reserved space using tune2fs

The mountpoint (/u01) on which I had installed Oracle E-Business Suite was running out of space.   More frustratingly, almost 5GB of precious space was unavailable since it was reserved by the system. This being an installation on my laptop, hard disk space was at a premium.

[root@myapps ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/hda3 6.0G 178M 5.5G 4% /
/dev/hda1 99M 8.7M 85M 10% /boot
none 681M 0 681M 0% /dev/shm
/dev/hda7 2.0G 36M 1.9G 2% /tmp
/dev/hda8 95G 89G 1.3G 99% /u01
/dev/hda2 6.0G 1.9G 3.8G 34% /usr
/dev/hda6 3.0G 93M 2.8G 4% /var
[root@myapps ~]#

The 5GB of space was reserved because ext2 or ext3 filesystem by default allocate 5% of the available blocks for use by the root user. This allows the system to continue running if non-root users fill up the file system and also assists in preventing file fragmentation because the filesystem does not fill up completely.

The good news is that you an use the tune2fs utility to fully reclaim the reserved space. Be careful though not to reclaim all of the reserved space if the file system is used by the root user or for storing log/system files (such as /var and /tmp).

You can use tune2fs with the -l option to view the file system information.

[root@myapps ~]# tune2fs -l /dev/hda8
tune2fs 1.35 (28-Feb-2004)
Filesystem volume name: /u01
Last mounted on: <not available>
Filesystem UUID: e458ad7d-d6c7-481f-8476-e2cd878bd38c
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 12648448
Block count: 25276261
Reserved block count: 1263813
Free blocks: 1589667
Free inodes: 11888886
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1024
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Filesystem created: Mon May 23 21:44:24 2011
Last mount time: Tue Jan 31 07:12:49 2012
Last write time: Tue Jan 31 07:12:49 2012
Mount count: 44
Maximum mount count: -1
Last checked: Mon May 23 21:44:24 2011
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: d32dc62a-1aef-417e-a80e-50f8882bf946
Journal backup: inode blocks
[root@myapps ~]#

And then use the -m option to set the reserved space according to your needs. In this case, I have set the reserved space to 1% of the total space. (Note that the available space is now 5.1GB from the earlier 1.3GB…muchos happiness)

[root@myapps ~]# tune2fs -m 1 /dev/hda8
tune2fs 1.35 (28-Feb-2004)
Setting reserved blocks percentage to 1 (252762 blocks)
[root@myapps ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/hda3 6.0G 178M 5.5G 4% /
/dev/hda1 99M 8.7M 85M 10% /boot
none 681M 0 681M 0% /dev/shm
/dev/hda7 2.0G 36M 1.9G 2% /tmp
/dev/hda8 95G 89G 5.1G 95% /u01
/dev/hda2 6.0G 1.9G 3.8G 34% /usr
/dev/hda6 3.0G 93M 2.8G 4% /var
[root@myapps ~]#