Karmic incorrectly mounts USB disk (NTFS) as 700, cannot change behavior.

[Matthew Holtz]

Binary package hint: udev

Please see http://wwww.ubuntuforums.org/showthread.php?p=8312991#post8312991 for more info.

Basically, in Jaunty, when I plugged in my NTFS-formatted USB hard disk, it was mounted in /media with 777 permissions.

Somehow in Karmic this behavior has changed to 700. Someone made this decision, probably to improve security), deliberately without thinking about the effects it might have.

In my case, I have files on the disk that I wish to share with the world using Samba. I can no longer do that because of this issue.

Worse, I have no idea how to modify this default behavior.

I apologize if I filed this under the wrong package, but quite honestly I have no idea what package(s) or files are actually involved in mounting my disks. Is it udev? hal? gconf? automount? ntfs-3g? fdisk?

ProblemType: Bug
Architecture: i386
CustomUdevRuleFiles: 10-vboxdrv.rules 50-virtualbox-ose.rules
Date: Fri Nov 13 23:50:51 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: udev 147~-6
ProcCmdLine: root=UUID=413ee0d2-a680-427d-a836-d2fdaccb0ce6 ro quiet splash
ProcEnviron:
 PATH=(custom, user)
 LANG=ja_JP.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: udev
Uname: Linux 2.6.31-14-generic i686
dmi.bios.date: 09/24/2003
dmi.bios.vendor: Intel Corp.
dmi.bios.version: BF86510A.86A.0046.P10.0309241107
dmi.board.name: D865GBF
dmi.board.vendor: Intel Corporation
dmi.board.version: AAC25827-406
dmi.chassis.type: 2
dmi.modalias: dmi:bvnIntelCorp.:bvrBF86510A.86A.0046.P10.0309241107:bd09/24/2003:svn:pn:pvr:rvnIntelCorporation:rnD865GBF:rvrAAC25827-406:cvn:ct2:cvr:

[Ksteve (ksteve123)]

I'm in the same boat... saw a recommendation to add my external ntfs drive to fstab and set permissions there but that doesn't work = get an error saying ntfs-3g was not compiled to allow changing permissions. Not good.

[GodLikeCreature (ultrachem)]

I have the same problem. I have a 1TB external drive that contains most of my media: music, movies, documents, etc. Those are not private files, and indeed I want for them to be available across sessions. However, the drive permissions are 700 for the user that was entered when the installation happened. However, users added later are not able to access this drive.

I personally think the behaviour in Jaunty made more sense, and would like to have it back in Karmic.

[Martin Pitt (pitti)]

Indeed, directories have 700 permissions, and files have 777.

[Björn Nilsson (bni-swe)]

Im also affected by this bug. Also why on earth was 777 choosen for files. Now every file I have backup for on my external drive ges execute permissions when i copy then back to my system.

executable jpg:s...

[Phil (pjb1997)]

I have this problem also. I am a novice at Ubuntu (and Linux in general), but I had managed to set up an old PC with dual boot to XP and Jaunty on my simple home network and was able to exchange files and share an entire external USB drive attached to the PC with the entire network by using Samba, but now I cannot. I upgraded without thoroughly looking through the known issues or else I may have decided not if I had read this bug. Will this get fixed you think, or should I re-install 9.04?

[Lev Abashkin (lev-abashkin)]

Same problem here. I'm using multiseat setup and removable media like usb sticks or memory cards are mounted with drwx------ permissions. All directories on media have these permissions as well. Files have -rwxr-xr-x permissions. This bug appeared after update not long time ago, and everything worked fine before. I find this behavior very unpleasant. Ubuntu maintainers should really make more testing before pushing updates.

[Lev Abashkin (lev-abashkin)]

... My media is formated as FAT, so this is not only NTFS problem.

[itsjustarumour (itsjustarumour-gmail-deactivatedaccount-deactivatedaccount)]

+1 for this bug. Like Lev Abashkin, I am using "removable media like usb sticks or memory cards are mounted with drwx------ permissions. All directories on media have these permissions as well. Files have -rwxr-xr-x permissions".

[Lev Abashkin (lev-abashkin)]

After some research I found that mount options for devicekit-disks were hardcoded into it. So I made a patch to fix it. It conflicts with one of the patches from devicekit-disks source package, so you have to add it in "patches" directory and mention it in the end of "series" file.

[Matthew Holtz (matthew-holtz)]

I'd love to test the patch. What do I need to do?

[Lev Abashkin (lev-abashkin)]

Something like this :

mkdir devkit-disks
cd devkit-disks
apt-get source devicekit-disks
wget http://launchpadlibrarian.net/36995686/10-fix-vfat-ntfs-udf-permissions.patch
cp 10-fix-vfat-ntfs-udf-permissions.patch devicekit-disks-007/debian/patches
echo "10-fix-vfat-ntfs-udf-permissions.patch" >> devicekit-disks-007/debian/patches/series
cd devicekit-disks-007
dch -l custom "Mount permissions fix."
dpkg-buildpackage -b -us -uc -rfakeroot
dpkg -i ../devicekit-disks_007-2ubuntu4custom1_amd64.deb

If you don't have some programs required for this sequence install them. Last command will install the package, package name is for amd64 architecture, substitute it if you have another one.

[Lev Abashkin (lev-abashkin)]

Oh, last command also requires superuser powers: sudo dpkg - i ../devicekit-disks_007-2ubuntu4custom1_amd64.deb

[Matthew Holtz (matthew-holtz)]

I can confirm that patch fixes it for me.

[X-Ander (x-ander)]

Hello! I'm very interesting in solving this problem too. Here is what I have found. Sorry for my (probably) bad English.

The mount options are not hardcoded in devkit-disks-device.c. Only their default values are set in the structures vfat_defaults, ntfs_defaults etc. The function devkit_disks_device_filesystem_mount allows to set different options while mounting (see given_options argument). This function should be called via D-Bus as the method FilesystemMount of the interface org.freedesktop.DeviceKit.Disks.Device. I'm not familiar with D-Bus so I have not understood who, where, and how calls that method. But I think the error must be fixed in the caller.

[Lev Abashkin (lev-abashkin)]

Thanks for clarification. Since devicekit-disks has no configuration files to setup default mount options and Karmic has broken gnome+devkit infrastructure we still have these options hardcoded. Best thing we can do now is check 10.04 alphas and betas for this bug and prevent it from lingering over another six months.

[[e-mail] (bl-main72)]

Hi,
I was on ubuntu server 2.6.28-16 with ubuntu desktop 9.04. All my external disk ( NTFS format ) connected in USB had been with owner: group root. Which I need for my anonymous FTP acces.
I have just done the migration to ubuntu server 2.6.31-17 with ubuntu desktop 9.10.
Unfortunatly all those external USB disk are now with owner:group myname.
So noboby ( anonymous ) can now acces through my FTP to those disk.

I tryed to install the patch but
(sorry as I am french, most of the comment notes are in French )

At the step
:~/extdisk/devicekit-disks-007$ dpkg-buildpackage -b -us -uc -rfakeroot
dpkg-buildpackage : définir CFLAGS à la valeur par défaut : -g -O2
dpkg-buildpackage : définir CPPFLAGS à la valeur par défaut :
dpkg-buildpackage : définir LDFLAGS à la valeur par défaut : -Wl,-Bsymbolic-functions
dpkg-buildpackage : définir FFLAGS à la valeur par défaut : -g -O2
dpkg-buildpackage : définir CXXFLAGS à la valeur par défaut : -g -O2
dpkg-buildpackage: paquet source devicekit-disks
dpkg-buildpackage: version source 007-2ubuntu4custom1
dpkg-buildpackage: source changé par myname <email address hidden>
dpkg-buildpackage: architecture hôte amd64
dpkg-checkbuilddeps : dépendances de construction non trouvées : debhelper (>= 7) cdbs autotools-dev quilt gtk-doc-tools intltool (>= 0.40.0) libdbus-glib-1-dev (>= 0.74-4) libdbus-1-dev (>= 1.0) libglib2.0-dev (>= 2.15) libgudev-1.0-dev libpolkit-gobject-1-dev (>= 0.92) libpolkit-backend-1-dev (>= 0.92) libparted1.8-dev (>= 1.8.8) libdevmapper-dev (>= 2:1.02) libatasmart-dev (>= 0.14) libsgutils2-dev zlib1g-dev libudev-dev (>= 0.142) uuid-dev libselinux-dev
dpkg-buildpackage: avertissement: Dépendances de construction et conflits non satisfaits ; échec.
dpkg-buildpackage: avertissement: (Utilisez l'option -d pour forcer.)
:~/extdisk/devicekit-disks-007$

When i try to go by the usual step to compilation system ( configure / make / make install )
At the end of ./configure command get this result
checking for sg_ll_inquiry in -lsgutils2... no
configure: error: libsgutils2 is needed

I try to install this library file
~/extdisk/devicekit-disks-007$ sudo apt-get install libsgutils2
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Aucune version du paquet libsgutils2 n'est disponible, mais il existe dans la base
de données. Cela signifie en général que le paquet est manquant, qu'il est devenu obsolète
ou qu'il n'est disponible que sur une autre source
Cependant les paquets suivants le remplacent :
  libsgutils2-2
E: Aucun paquet ne correspond au paquet libsgutils2

So I try
sudo apt-get install libsgutils2-2
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
libsgutils2-2 est déjà la plus récente version disponible.
libsgutils2-2 passé en « installé manuellement ».
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.

Thanks for your help

[Lev Abashkin (lev-abashkin)]

You do not have dependencies installed. Run "sudo apt-get build-dep devicekit-disks" to install them.

[[e-mail] (bl-main72)]

Hi Lev
Thanks for this help
But I have this result
Traitement des actions différées (« triggers ») pour « install-info »...
Traitement des actions différées (« triggers ») pour « man-db »...
Traitement des actions différées (« triggers ») pour « doc-base »...
Processing 7 added doc-base file(s)...
Registering documents with scrollkeeper...
Paramétrage de g15daemon (1.9.5.3-3) ...
Starting g15daemon: invoke-rc.d: initscript g15daemon, action "start" failed.
dpkg : erreur de traitement de g15daemon (--configure) :
 le sous-processus script post-installation installé a retourné une erreur de sortie d'état 1
dpkg : des problèmes de dépendances empêchent la configuration de g15macro :
 g15macro dépend de g15daemon ; cependant :
 Le paquet g15daemon n'est pas encore configuré.
dpkg : erreur de traitement de g15macro (--configure) :
 problèmes de dépendances - laissé non configuré
Paramétrage de m4 (1.4.13-2) ...
Pas de rapport Apport écrit car le message d'erreur indique que c'est la suite d'une erreur précédente.
                       Paramétrage de autoconf (2.64-1ubuntu1) ...
Ignoring install-info called from maintainer script
The package autoconf should be rebuild with new debhelper to get trigger support
Ignoring install-info called from maintainer script
The package autoconf should be rebuild with new debhelper to get trigger support
Ignoring install-info called from maintainer script
The package autoconf should be rebuild with new debhelper to get trigger support

Paramétrage de autotools-dev (20090427.1) ...
Paramétrage de automake (1:1.11-1) ...
update-alternatives: utilisation de « /usr/bin/automake-1.11 » pour fournir « /usr/bin/automake » (automake) dans mode automatique.

Paramétrage de html2text (1.3.2a-14) ...

Paramétrage de po-debconf (1.0.16) ...
Paramétrage de debhelper (7.3.15ubuntu3) ...
Paramétrage de fdupes (1.50-PR2-2) ...
Paramétrage de intltool (0.41.0-0ubuntu1) ...
Paramétrage de cdbs (0.4.59ubuntu4) ...
Paramétrage de docbook (4.5-4) ...

Paramétrage de libsp1c2 (1.3.4-1.2.1-47build2) ...

Paramétrage de jade (1.2.1-47build2) ...

Paramétrage de docbook-dsssl (1.79-6) ...

Paramétrage de sp (1.3.4-1.2.1-47build2) ...
Paramétrage de docbook-to-man (1:2.0.0-27) ...
Paramétrage de docbook-xsl (1.75.1+dfsg-1) ...

Paramétrage de docbook-xsl-doc-html (1.75.1-1) ...
Paramétrage de libtool (2.2.6a-4) ...
Paramétrage de gnome-common (2.28.0-1) ...
Paramétrage de gtk-doc-tools (1.11-4) ...

Paramétrage de libatasmart-dev (0.16-1) ...
Paramétrage de libdbus-1-dev (1.2.16-0ubuntu9) ...
Paramétrage de libglib2.0-dev (2.22.3-0ubuntu1) ...
Paramétrage de libdbus-glib-1-dev (0.80-4ubuntu1) ...
Paramétrage de libdevmapper-event1.02.1 (2:1.02.27-4ubuntu7) ...

Paramétrage de libdevmapper-dev (2:1.02.27-4ubuntu7) ...
Paramétrage de libudev-dev (147~-6.1) ...
Paramétrage de libgudev-1.0-dev (1:147~-6.1) ...
Paramétrage de libltdl-dev (2.2.6a-4) ...
Paramétrage de libsys-hostname-long-perl (1.4-2) ...
Paramétrage de libmail-sendmail-perl (0.79.16-1) ...
Paramétrage de libparted1.8-dev (1.8.8.git.2009.06.03-1ubuntu6) ...
Paramétrage de libpolkit-gobject-1-dev (0.94-1ubuntu1) ...
Paramétrage de libpolkit-backend-1-dev (0.94-1ubuntu1) ...
Par...

[[e-mail] (bl-main72)]

Hi Lev
I shutdown the computer
Restarted it
Launch again sudo apt-get build-dep devicekit-disks
With about some same error
SI tryed by removing
g15macro
g15stats
g15daemon

then i launch again : dpkg-buildpackage -b -us -uc -rfakeroot
The script looked to wroks well
Then I launch also dpkg -i ../devicekit-disks_007-2ubuntu4custom1_amd64.deb as root
No error too
I wait my next restart to check if now the access is ok

Thanks again for your help

[Stefan Schindler (stefan-schindler)]

The patch fixed it for me, too. Thx!!

As long as we linux users actually want to show off with our systems and then end up grepping in /etc/udev/rules.d for umask, then applying patches and such, while the person we wanted to show how easy to use our os has become faints in seeing hierogylphes at the terminal WE WILL BE LAUGHED AT FOR A DAMN GOOD REASON!

Nevermind, haha!

So what to do with the package devicekit-disks now? Put on hold?

[Matthew Holtz (matthew-holtz)]

I agree with your sentiment, Stefan. Although I am a long time Linux user, I tire when I have to deal with issues like this. Especially when they change from one distribution to the next.

We can try to pretend that making someone edit a text file buried somewhere in /etc is a way an acceptable way to change a default behavior, but for the rest of the world, it's a joke. Situations like this are why the year that Linux will take over the desktop is *always* next year.

If we ever as a group wish to see Linux adopted on the desktop, we need more top-down SYSTEM LEVEL design, not component-level design where each component is sub-optimized at the expense of the system as a whole.

But I digress.