Ok. on one computer (mandria 2008.0) i plug in the drive (entire drive, 1 partition, NTFS), in kde/gnome, drive pops up, mounted as ntfs-3g. on every other mandriva 2008.0 install in my house, i have to manually mount it (mount -t ntfs-3g /dev/sda1 /media/hd). i have a bunch of noobies at home, so its driving them and me nuts. i don't know/remember what i did to this one computer to make it special, other than using it all the time.

kernel messages when plugging it into any other install:

kernel: FAT: bogus number of reserved sectors
kernel: VFS: can't find a valid FAT filesystem on dev sda1

it would appear that i don't have ntfs support on the machine, but when i do

mount -t ntfs /dev/sda1 /media/hd

it works fine, kernel says

kernel: NTFS volume version 3.1

i can read files just fine.

any ideas?

Write a scrip to do the mounting for them- that way they only need to double click on the script and the drive will mount.

I don't use Mandriva, but I suggest you compare the /etc/fstab on the "working" system with the other systems. Perhaps you have an entry in there that needs to be copied.

my point is that it is a removable drive, so looking at /etc/fstab is a dead end. what should work at least is the kernel ntfs driver loading. i checked /proc/filesystems and its there, as well as fuseblk and ntfs-3g. it works manually, but not automatically.

and i would have to copy the script to every linux computer in the house. if this was a business of 500+ machines, this would not scale very well. however, the machine that does it automatically has a ntfs-3g entry, but for the windows partition (dual boots). the other machine in the house that dual boots, and has the ntfs-3g entries in /etc/fstab, has the same problem.

i suspect that the automatic mounting code for kde/gnome/maybe hal/udev? assumes all removable drives are fat, and this one is not. i have no idea how to check that assumption.
here is the fstab for the working machine:

/dev/hda2 / reiserfs notail,noatime,user_xattr 1 1
/dev/hda4 /home reiserfs notail,noatime,user_xattr 1 2
/dev/cdrom /media/cdrom auto umask=0022,user,iocharset=utf8,noauto,ro,exec 0 0
/dev/fd0 /media/floppy auto umask=0022,user,iocharset=utf8,noauto,exec,flush 0 0
/dev/hda1 /mnt/windows ntfs-3g rw,umask=000,defaults 0 0
none /proc proc defaults 0 0
/dev/hda3 swap swap defaults 0 0

maybe related, but on the floppy drive on the machine in question, the /etc/fstab has to look like this:

/dev/fd0 /media/floppy vfat umask=0022,user,iocharset=utf8,noauto,exec,flush 0 0

if i try to change vfat to auto, it doesn't work. same for the cdrom, its set to udf,iso9660

Which desktops do your computers use? HAL/udev/PolicyKit/dbus and the desktop environment work together. HAL detects the drive when it is plugged in. Udev creates the node. Polkit determines whether the desktop user is allowed to mount removable drives. The desktop environment communicates via dbus.

The problem could be in how the desktop environment is configured. Or it could be that a needed service like dbusd isn't running. If you boot with the noacpi option, for example, udevd and dbusd will not run.

Monitoring the kernel messages with "sudo tail -f /var/log/messages" while inserting the usb cable may provide clues as well. My system, SuSE, won't automount a drive if it is listed in /etc/fstab; while Ubuntu, edits the /etc/fstab file and adds an entry.

on the successful computer, here are the kernel messages:

Jul 13 22:08:14 localhost kernel: scsi 0:0:0:0: Direct-Access Seagate FreeAgent 102D PQ: 0 ANSI: 4
Jul 13 22:08:26 localhost kernel: sd 0:0:0:0: [sda] Spinning up disk....ready
Jul 13 22:08:26 localhost kernel: sd 0:0:0:0: [sda] 2930277168 512-byte hardware sectors (1500302 MB)
Jul 13 22:08:26 localhost kernel: sd 0:0:0:0: [sda] Write Protect is off
Jul 13 22:08:26 localhost kernel: sd 0:0:0:0: [sda] Assuming drive cache: write through
Jul 13 22:08:26 localhost kernel: sd 0:0:0:0: [sda] 2930277168 512-byte hardware sectors (1500302 MB)
Jul 13 22:08:26 localhost kernel: sd 0:0:0:0: [sda] Write Protect is off
Jul 13 22:08:26 localhost kernel: sd 0:0:0:0: [sda] Assuming drive cache: write through
Jul 13 22:08:26 localhost kernel: sda: sda1
Jul 13 22:08:26 localhost kernel: sd 0:0:0:0: [sda] Attached SCSI disk
Jul 13 22:08:26 localhost kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Jul 13 22:08:30 localhost ntfs-3g[11430]: Version 1.5012 integrated FUSE 27
Jul 13 22:08:30 localhost ntfs-3g[11430]: Mounted /dev/sda1 (Read-Write, label "FreeAgent Drive", NTFS 3.1)
Jul 13 22:08:30 localhost ntfs-3g[11430]: Cmdline options: rw,nosuid,nodev,uhelper=hal,locale=en_US.UTF-8
Jul 13 22:08:30 localhost ntfs-3g[11430]: Mount options: rw,nosuid,nodev,uhelper=hal,silent,allow_other,nonempty,relatime,fsname=/dev/sda1,blkdev,blksize=4096
Jul 13 22:08:30 localhost hald: mounted /dev/sda1 on behalf of uid 503
Jul 13 22:09:21 localhost ntfs-3g[11430]: Unmounting /dev/sda1 (FreeAgent Drive)
Jul 13 22:09:21 localhost hald: unmounted /dev/sda1 from '/media/FreeAgent Drive' on behalf of uid 503

Jul 13 22:22:04 localhost kernel: usb 5-1: USB disconnect, address 7


i am using mandriva 2008.0

the unsucessful computers do the FAT bogus number thing mentioned earlier.

i also noticed that the successful computer does not bother /etc/fstab, while the unsuccessful computers do.



my machines don't have dbusd running, nor policykit. they do have gnome-volume-manager (both machines have the same version). i tried looking for configuration files for both hal and gnome-volume-manager. there is no hald.conf, nor gnome-volume-manager.conf. is there a way to trace the commands haldaemon uses to mount the drives?

ok. i am making this too hard.
bottom line: my house is the only place where when you plug in a ntfs removable volume, you get FAT errors. apparently, everywhere else on the net, they get the ntfs read-only kernel driver. how do i fix that?

I don't think I caught which desktop environment you are running.

Look at this part of post #8. The ntfs-3g[11430] option is what interests me here. What is the process with the PID of 11430? (Repeating the monitoring experiment, the process number may be different.)
Look at /proc/11430/cmdline. It may indicate which program or daemon is looking at the ntfs volume.

Also check if you have a libvolume_id package. It examines filesystems and determines there type. I don't know for certain if the system uses it as well, but it could be the difference between the systems you looking at.

Look at /proc/filesystems. Do the items ntfs and those with fuse in their names match between the systems.

Look at `ls /sbin/mount.*'. Do you see mount.ntfs-3g, mount.fuse and may be something with "hal" in it's name?

compare the output of 'ps -e' on your systems. Does the one working have daemon running that isn't in the others?

---

Sorry I'm not being more helpful. This is a fuzzy and fast evolving area.
I don't have an external NTFS drive to plug in and compare, and my system probably does it differently than yours.

I just noticed that, on my Fedora system, the NTFS plugin for the gvfs is a separate module (ntfsprogs-gnomevfs). Perhaps you need that installed on the other systems, but have it installed on yours.

this behavior happens in both gnome and kde.


plugged in the drive on success_machine:

[root@localhost jayjay]# cat /proc/6775/cmdline
/sbin/mount.ntfs-3g/dev/sda1/media/FreeAgent Drive-orw,nosuid,nodev,uhelper=hal,locale=en_US.UTF-8
[root@localhost jayjay]#

[root@localhost 6775]# rpm -qa | grep libvolume_id
libvolume_id0-114-7mdv2008.0

//same version on both computers

[root@localhost 6775]# cat /proc/filesystems
nodev sysfs
nodev rootfs
nodev bdev
nodev proc
nodev debugfs
nodev securityfs
nodev sockfs
nodev pipefs
nodev anon_inodefs
nodev futexfs
nodev tmpfs
nodev inotifyfs
nodev devpts
ext2
cramfs
nodev ramfs
nodev hugetlbfs
nodev mqueue
reiserfs
nodev usbfs
nodev fuse
fuseblk
nodev fusectl
nodev binfmt_misc


on the fail_computer, it also lists ext3, udf, and iso9660.


[root@localhost 6775]# rpm -qa | grep gnome | grep vfs
gnome-vfs-obexftp-0.4-1mdv2008.0
gnome-python-gnomevfs-2.20.0-1mdv2008.0
gnome-vfs2-2.20.0-2mdv2008.0
libgnome-vfs2_0-2.20.0-2mdv2008.0
gstreamer0.10-gnomevfs-0.10.14-1mdv2008.0


the fail_computer doesn't have the obexftp package, because i don't use my bluetooth dongle on it.


this is interesting....
sucess_machine:

[root@localhost 6775]# rpm -qa | grep fuse
fuse-kernel-2.6.22.9-laptop-1mdv-2.7.0-6mdv2008.0
fuse-kernel-laptop-latest-2.7.0-1.20080506.6mdv2008.0
libfuse2-2.7.1-2mdv2008.0
fuse-kernel-2.6.22.19-laptop-2mdv-2.7.0-6mdv2008.0

fail_machine:
[root@localhost ~]# rpm -qa | grep fuse
fuse-2.7.0-6mdv2008.0
libfuse2-2.7.0-6mdv2008.0
dkms-fuse-2.7.1-2mdv2008.0


any suggestions?

Look at the contents of the dkms-fuse and fuse-kernel packages. I suspect that they both contain the fuse kernel modules, but have been packaged differently.

FYI, if you use "cat /proc/<PID>/cmdline | tr '\0' ' ' ", the result will have NULL chars replaced with spaces, making it more readable.

/sbin/mount.ntfs-3g /dev/sda1 /media/FreeAgent\ Drive -o rw,nosuid,nodev,uhelper=hal,locale=en_US.UTF-8

Look at "rpm -qf /sbin/mount.ntfs-3g". It will identify the package supplying this file. What other files are in it. Anything dealing with HAL?

My system doesn't have the "uhelper=hal" part. Maybe look and see if you have the "ntfsprogs-gnomevfs" package, and check it's contents. Try "locate uhelper". Look in your "man mount" page. Mine has nothing about a uhelper option, but mentions the /sbin/mount.* programs.

I think there is a hal helper script somewhere that is used to identify the type of partition, and then mount it. On my system, in a previous version, there would be a matching rule in /etc/udev/udev.rules/* that matched "sd*" and had RUN+= at the end. You could search for such a rule. "grep 'sd\*' /etc/udev/udev.rules/* . With my current version, this was moved out of udev (probably due to PolicyKit and ConsoleKit being used for granting user permissions) and udev simply creates the /dev/disk/by-id/<device_node> link, and no longer creates a node with the users group changed. Now the node has an ACL granting the user permission. I mention this so it won't be a surprise if looking at the udev rules is a dead-end.

Also look at the "file" command. It may also be used to identify the type of filesystem on the partition.
Try "sudo file -s /dev/sda1" on the systems and see if the ntfs filesystem is detected on all of them.

Look for shell scripts, perl scripts and python scripts in /usr/lib/, /lib/ and /var/lib/. HAL often uses python for helper scripts. One of them may be identifying the filesystem and calling mount.ntfs-3g.

Good Luck!

running rpm -qa /sbin/mount.ntfs-3g points me to the ntfs-3g package, in which i found /usr/share/hal/fdi/policy/10osvendor/10-ntfs-3g-policy.fdi

here are its contents:

<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
<!-- mount ntfs volume with the ntfs-3g driver to enable write support -->
<device>
<match key="volume.fstype" string="ntfs">
<match key="@block.storage_device:storage.hotpluggable" bool="true">
<merge key="volume.fstype" type="string">ntfs-3g</merge>
<merge key="volume.policy.mount_filesystem" type="string">ntfs-3g</merge>
<append key="volume.mount.valid_options" type="strlist">locale=</append>
</match>
</match>
</device>
</deviceinfo>


it looks like to me when it finds an ntfs drive, replace the kernel driver with ntfs-3g. this file is on both machines.


i did file /dev/sda1, it told me block special (8/1), i don't know what that means.

when i did mount /dev/sda1 /media/hd, it automatically detected the ntfs partition, loaded the read-only module, and i was good to go.

on the fail_machine, i have removed totally ntfs-3g and fuse. same problem. I tried the same drive, same fat bogus sector errors. manually it still works.