Problem accessing sda3 in Ubuntu after mounting it in Fedora

Ask Fedora
1

Got a triple boot laptop with Ubuntu 24.04 (sda5), Win7 (sda2), and Fedora 43 (sda7) using ubuntu grub bootloader. Use drive E (sda3) as storage drive accessible to all three OS’s. No problem writing/reading from Ubuntu or Windows to it, and Fedora read from it as well - BUT, I wrote to it from Fedora and even though Windows can still read/write from it, Ubuntu can’t mount it anymore ~ get this:

image
image420×263 22.3 KB

Had similar issue with Fedora mounting the Ubuntu drive (sda5) to just copy something from it, then afterwards unable to launch Ubuntu until I ran the ‘restore’ repairs from the Ubuntu grub sub-menu on it to get it running again - so quit mounting the Ubuntu sda5 in Fedora! Then this happens… Ubuntu is fine, just the storage partition gets error when mounting…

Question is, what the heck did Fedora do to this drive by simply writing to it?!? Seems to have overwritten permissions or something - I now have to open a terminal in Ubuntu after booting, type sudo mount /dev/sda3 /media/batgirl, and it’ll mount, but had to run sudo chmod 777 /media/batgirl just once and it let me have ability to write, too.

Tried getting help here, but to no avail (except workaround above):
Problem accessing sda3 in Ubuntu after mounting it in Fedora - linuxconfig.org

Anybody got any ideas what caused this and/or how to undo it ~ meanwhile quit mounting sda3 in Fedora, too!!!

2

One problem that has been revealed in the past is that when sharing a device between windows and linux is that the user must always ensure that fast boot is disabled in windows.

It seems that if windows has the device and fast boot (somewhat similar to suspend on linux) is enabled when windows is shut down there is something on the device that gets disturbed when mounted with linux (or may even prevent linux using the device). ISTR that disabling fast boot on windows prevents this happening and that then a shutdown of windows totally releases the device for other use.

Be aware that not all linux distros are the same and you apparently may be seeing some of the differences.

3

Very old Windoz 7 - no ‘fast boot’ available on very old Gateway 475M laptop… btw - never had any issue with sda2 (win7), sda3 (E drive) and sda5 (Ubuntu 20.04, then 22.04, and now 24.04) for YEARS until installed Fedora 43 - so problem is Fedora 43 writing to sda3 screwed it up for Ubuntu, but not windoz, so focus on fast boot? really?

4

A drive shared between the 3 OSes (windows, Ubuntu, and Fedora) must of necessity be formatted as ntfs, which means that it must be windows (NTFS or VFAT) related even if linux activated.

There has never, AFAIK, been an issue with sharing a device between linux OSes when it is a linux file system such as ext4. Your situation, by design, forces the windows filesystem to be in the middle of whatever is happening with failures to share devices.

You claim that one drive can no longer be accessed by ubuntu and another drive can no longer be accessed by fedora. Look at the common factors between the 2 drives – a windows file system.

You had not previously stated anything about the hardware in use, the very old Gateway 475M laptop which you now identified. It is not surprising that you are having an issue with us expecting you to be working with a modern bios and hardware. Almost all systems sold in recent years have a fast boot option in bios as well as all windows OSes (at least since windows 8) have the fast boot option in the OS (though it now has a different name). An almost 20 year old laptop is expected to be much different than a modern hardware laptop.

It is probably legacy boot only, so would not have secure boot either.

An additional factor in play here is the ntfs version used to format the drives for windows. It has changed since windows 7 was in play and the ntfs3 file system that fedora expects today was not in use during the time of win7.

Potentially ubuntu is using one version of ntfs and fedora is using a different version. Not enough difference to break windows but enough to not be compatible with the different linux distros.

5

partition was created by Ubuntu 20.04 using NTFS - Fedora 43 sez it’s:
NTFS/exFAT/HPFS in ‘Disks’,
and in nautilus it sez it’s:
Fuse Filesystem

All the same drive (sda) - just different partitions… Fedora accesses it fine, so does win7 - just Ubuntu accessed if fine until Fedora wrote one file to it so it now has to use workaround merely to mount it…

6

I apologize for terming that incorrectly.

Same in management – a block device with a file system. Different partition means different file system – which means a block device that can be managed differently – especially when used by different OSes.

7

It’s more likely that ubuntu has added some dirty patches to their packages that breaks compatibility with other O/S.

8

If I got it right, the problem happens on Ubuntu from nautilus (or whatever file
browser GUI) using fuse, but not as root using mount (mount.ntfs ntfs-3g).

A workaround could thus be to declare this mount in /etc/fstab on Ubuntu (and also
on Fedora for homogeneity). Making this mount automount only would be better since I
guess that this filesystem is not used often. Do not use /media for the mountpoint
since its usage should be restricted to the GUI.

Add thus for example to /etc/fstab:

/dev/sda3 /E ntfs    defaults,x-systemd.automount       0 0

Then reboot or execute as root:

systemctl daemon-reload # Make systemd re-read /etc/fstab
systemctl start E.automount

Verify that the mount works, from the GUI on /Eor with: ls /E
findmnt /E should then gives something like:

findmnt /E
TARGET SOURCE    FSTYPE OPTIONS
/E     systemd-1 autofs rw,[...]
/E     /dev/sda3 ntfs   rw,[...]

The defaults options should allow everybody full read, write, execution and
directory browsing permissions (at least on Fedora). See: man ntfs-3g

9

@firebat: have you got time to test the workaround I suggested ?

11

currently using “open a terminal in Ubuntu after booting, type sudo mount /dev/sda3 /media/batgirl, and it’ll mount” as a manual workaround for the once in a blue moon I actually need to write to sda3/E-drive… the fstab edit actually scares me

:woozy_face:

…but will keep looking at possibly doing it once I do a G4L lzop image of my ubuntu in case it screws something up :wink:

12

Hi,

That’s an interesting workaround — it makes sense if the issue is related to how the GUI mounts the filesystem versus a manual mount.

What I find surprising though is that it worked fine for years, and the only change seems to be writing to the partition from Fedora.

So I’m wondering if the root issue might actually be the NTFS filesystem state itself, rather than just the mounting method.

The fact that:

  • manual mount works
  • but the GUI mount fails

could suggest that Ubuntu is being stricter when the filesystem is not in a fully clean state.

A couple of simple tests might help confirm that:

Option 1 (Windows)

Boot into Windows and run:

chkdsk E: /f

Then reboot into Ubuntu and try mounting it normally again.

Option 2 (from Ubuntu)

You can also try:

sudo ntfsfix /dev/sda3

If either of these fixes the issue, it would point more toward a filesystem consistency problem than a mounting configuration issue.

Curious to know if that changes anything.

Regards,
G/T

13

Understandable.

Another way to do that is to create:

  • /etc/systemd/system/E.mount
[Unit]

[Mount]
What=/dev/sda3
Where=/E
Type=ntfs

Then execute systemctl start E.mount when you need it.

You can add if you want:

  • /etc/systemd/system/E.automount
[Unit]

[Automount]
Where=/E

[Install]
WantedBy=local-fs.target

and enable it with systemctl --now enable E.automount. Attempting to access /E will mount it.

Disable it in case of trouble.

14

Here’s the results:

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\gateway12>chkdsk e: /f
The type of the file system is NTFS.

CHKDSK is verifying files (stage 1 of 3)...
  5376 file records processed.
File verification completed.
  1 large file records processed.
  0 bad file records processed.
  292 EA records processed.
  1 reparse records processed.
CHKDSK is verifying indexes (stage 2 of 3)...
  6078 index entries processed.
Index verification completed.
  0 unindexed files scanned.
  0 unindexed files recovered.
CHKDSK is verifying security descriptors (stage 3 of 3)...
  5376 file SDs/SIDs processed.
Security descriptor verification completed.
  351 data files processed.
CHKDSK discovered free space marked as allocated in the
master file table (MFT) bitmap.
CHKDSK discovered free space marked as allocated in the volume bitmap.
Windows has made corrections to the file system.

  51199999 KB total disk space.
  24701796 KB in 4198 files.
      1856 KB in 353 indexes.
         0 KB in bad sectors.
     72895 KB in use by the system.
     65536 KB occupied by the log file.
  26423452 KB available on disk.

      4096 bytes in each allocation unit.
  12799999 total allocation units on disk.
   6605863 allocation units available on disk.

C:\Users\gateway12>

And YES! It did mount ‘normally’… so, that’s all it was, Fedora left the above instability until chkdsk E: /f was run on it…

You’re AWESOME!!!

15

There are multiple NTFS drivers. See the LWN article below for some details about the state of NTFS support in Linux.

It sounds like you were using three different NTFS drivers to access your filesystem ntfs (a.k.a. ntfs3), ntfs-3g, and the Windows native driver. I’m not surprised that your filesystem ended up in a bad state. Personally, I would use exFAT. That codebase is the same across all the distros. Microsoft contributed it to the Linux kernel to ensure 100% compatibility.[1]

  1. ↩︎

16

…would that include Windows 7?

17

I don’t remember if Windows 7 had exFAT support, but if it does, then yes, it would probably be using the same exFAT driver. I doubt that code has changed much since it was released.

18

Seems that sda3 is already exFAT:

sda3
sda3694×294 34.8 KB

19

It looks like it says NTFS to me. Note that the partition type is not the same thing as the filesystem format. It appears to be saying that your partition’s type code is set to a generic value that permits NTFS or exFAT (or HPFS).