kernel-packages team mailing list archive
-
kernel-packages team
-
Mailing list archive
-
Message #39407
[Bug 1261524] Re: Same USB HDD gets different mounting behaviour depending on filesystem used?
Joseph:
I don't. This was on my primary workstation running Saucy and because I
needed the drive, I couldn't just sit on it while debugging this. So I
formatted it in ext4 as noted above, and worked around the root
ownership.
I'm pretty sure the permissions thing when it was formatted NTFS is due
to NTFS not really supporting unix-style permissions, however, I was a
bit taken that I was unable to make a script executable (AFAIK,
executables on WIndows are marked Executable somehow on NTFS drives).
But that's a fairly complex issue, I"m led to believe.
Once I chown'd the drive with my user name, the change stuck and now
when I plug it in, I get the correct user/group ownership.
I just found it very odd that my drive, after being formatted in ext4,
when plugged in, was UID/GID root but still mounted to
/media/MYUSERNAME/DISKLABEL
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1261524
Title:
Same USB HDD gets different mounting behaviour depending on filesystem
used?
Status in “linux” package in Ubuntu:
New
Bug description:
Running Saucy on my laptop. I have a 2TB USB3.0 external HDD that is
factory formatted in NTFS.
When I first plugged it in, it was mounted like so:
drwx------ 1 bladernr bladernr 4096 Dec 16 12:47 Alexandria
and I was able to start creating a python script inside the disk :
-rw------- 1 bladernr bladernr 179 Dec 16 12:47 update-library
However, it was absolutely impossible to make that script executable.
I tried remounting the drive by setting umaks, dmask and fmask to
0777, and I also tried setting the exec option. But there was
absolutely no way I could make that script executable.
So I reformatted the disk in ext4. This time, the drive mounted with
ownership being root:root. Thus, still unusable, but even moreso this
time because after I plugged in my hard disk, I was unable to even
read the disk, let alone try to copy data or create files on it.
In order to make my USB disk actually usable, as my user, I had to
take the additional step of using chown on a cli. A user shouldn't
have to take extraordinary measures like this to make their external
HDD usable.
ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-15-generic 3.11.0-15.23
ProcVersionSignature: Ubuntu 3.11.0-15.23-generic 3.11.10
Uname: Linux 3.11.0-15-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.12.5-0ubuntu2.2
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC1: bladernr 2560 F.... pulseaudio
/dev/snd/controlC2: bladernr 2560 F.... pulseaudio
/dev/snd/controlC0: bladernr 2560 F.... pulseaudio
Date: Mon Dec 16 15:21:35 2013
HibernationDevice: RESUME=UUID=c2f4cbc3-a904-4dbf-acd4-0a28f482d683
InstallationDate: Installed on 2012-03-15 (641 days ago)
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20120307)
MachineType: Alienware M15x
MarkForUpload: True
ProcFB:
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.11.0-15-generic root=UUID=e7eedf5d-5aad-4230-b123-47162b1acea6 ro
RelatedPackageVersions:
linux-restricted-modules-3.11.0-15-generic N/A
linux-backports-modules-3.11.0-15-generic N/A
linux-firmware 1.116
SourcePackage: linux
UpgradeStatus: Upgraded to saucy on 2013-06-22 (177 days ago)
dmi.bios.date: 08/24/2010
dmi.bios.vendor: Alienware
dmi.bios.version: A08
dmi.board.vendor: Alienware
dmi.board.version: A08
dmi.chassis.type: 8
dmi.chassis.vendor: Alienware
dmi.chassis.version: A08
dmi.modalias: dmi:bvnAlienware:bvrA08:bd08/24/2010:svnAlienware:pnM15x:pvrA08:rvnAlienware:rn:rvrA08:cvnAlienware:ct8:cvrA08:
dmi.product.name: M15x
dmi.product.version: A08
dmi.sys.vendor: Alienware
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1261524/+subscriptions
References