[Help] TOS 7.0.0804 - NTFS USB drives fail to mount - StorageManager uses invalid gid=allusers

[DebuggaNB]

Issue summary

After upgrading my TNAS to TOS 7, external NTFS disks connected over USB are detected correctly by Storage Manager, but remain Unmounted.

I tracked the problem down to the ntfs-3g command being generated by TOS StorageManager.

StorageManager is passing:

Code: Select all

gid=allusers

to ntfs-3g. ntfs-3g requires the gid option to contain a numeric GID, so the mount fails.

I was able to reproduce the failure manually and then successfully mount the same filesystem by changing only this option from

Code: Select all

gid=allusers

to the numeric GID for the allusers group.


System / environment

TOS: 7.0.0804
Architecture: x86_64
Kernel: 5.15.59
External enclosure: Sabrent Dual SATA Bridge (USB)

Two GPT/NTFS disks are installed in the enclosure:

• 12 TB - label: PlexOffline
• 4 TB - label: 4tbEvac

ntfs-3g version:

Code: Select all

ntfs-3g 2021.8.22 integrated FUSE 28

USB detection works correctly

Both disks and their NTFS partitions are detected:

Code: Select all

NAME    SIZE FSTYPE LABEL       UUID
sdf    10.9T
├─sdf1   16M
└─sdf2 10.9T ntfs   PlexOffline <UUID-PlexOffline>

sdg     3.6T
├─sdg1   16M
└─sdg2  3.6T ntfs   4tbEvac     <UUID-4tbEvac>

TOS also remembers both volumes in:

Code: Select all

/etc/tos/config/usb_mount_map.json

However, their last_seen_path remains empty and neither filesystem is mounted.


StorageManager mount attempt

The StorageManager journal shows TOS attempting both RW and RO mounts:

Code: Select all

TNAS-NAS storagemanager: DEBUG /usr/bin/ntfs-3g -o rw,noatime,big_writes,async,iocharset=utf8,gid=allusers,dmask=007 /dev/sdf2 /Volume1/@usb/usb_PlexOffline
TNAS-NAS storagemanager: DEBUG /usr/bin/ntfs-3g -o ro,noatime,async,iocharset=utf8,gid=allusers,dmask=007 /dev/sdf2 /Volume1/@usb/usb_PlexOffline

TNAS-NAS storagemanager: DEBUG /usr/bin/ntfs-3g -o rw,noatime,big_writes,async,iocharset=utf8,gid=allusers,dmask=007 /dev/sdg2 /Volume1/@usb/usb_4tbEvac
TNAS-NAS storagemanager: DEBUG /usr/bin/ntfs-3g -o ro,noatime,async,iocharset=utf8,gid=allusers,dmask=007 /dev/sdg2 /Volume1/@usb/usb_4tbEvac

Neither attempt succeeds.


Reproducing the error manually

I created a temporary mountpoint and ran the same RO command being generated by StorageManager:

Code: Select all

/usr/bin/ntfs-3g -o ro,noatime,async,iocharset=utf8,gid=allusers,dmask=007 /dev/sdf2 /Volume1/@usb/test_PlexOffline

ntfs-3g immediately returns:

Code: Select all

'gid' option needs a decimal value

This appears to identify the reason both StorageManager mount attempts fail.


allusers group

On the TNAS:

Code: Select all

$ getent group allusers
allusers:x:997:guest,admin,SysAdminTron

Therefore the numeric GID on this system is:

Code: Select all

997

Same mount succeeds with numeric GID

I repeated the same mount, changing only

Code: Select all

gid=allusers

to

Code: Select all

gid=997

:

Code: Select all

/usr/bin/ntfs-3g -o ro,noatime,async,iocharset=utf8,gid=997,dmask=007 /dev/sdf2 /Volume1/@usb/test_PlexOffline

The command completed successfully.

findmnt then confirmed:

Code: Select all

TARGET                          SOURCE     FSTYPE   OPTIONS
/Volume1/@usb/test_PlexOffline  /dev/sdf2  fuseblk  ro,noatime,...

So:

Code: Select all

gid=allusers  -> mount fails
gid=997       -> mount succeeds

NTFS filesystem checks

I also checked both NTFS filesystems with ntfsfix in no-action mode before testing.

12 TB disk:

Code: Select all

$ ntfsfix -n /dev/sdf2
Mounting volume... OK
Processing of $MFT and $MFTMirr completed successfully.
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/sdf2 was processed successfully.

4 TB disk:

Code: Select all

$ ntfsfix -n /dev/sdg2
Mounting volume... OK
Processing of $MFT and $MFTMirr completed successfully.
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/sdg2 was processed successfully.

The issue therefore does not appear to be filesystem corruption or an NTFS dirty-state problem.


Native USB detection/retry also reproduces the problem

I manually retriggered the native TOS USB insert handler:

Code: Select all

/etc/udev/scripts/usb_operate insert sdf
/etc/udev/scripts/usb_operate insert sdg

StorageManager accepted both insert events successfully, but again generated the same ntfs-3g commands containing:

Code: Select all

gid=allusers

and both volumes remained unmounted.


Suspected cause

It appears StorageManager is passing the TOS group name:

Code: Select all

gid=allusers

directly to ntfs-3g.

ntfs-3g expects this option to contain a decimal/numeric GID.

StorageManager presumably needs to resolve the allusers group through the system group database before constructing the mount command.

For example, on this TNAS:

Code: Select all

allusers -> GID 997

and using:

Code: Select all

gid=997

successfully mounts the same filesystem.


Expected behavior

When an NTFS USB disk is detected, StorageManager should automatically mount it under:

Code: Select all

/Volume1/@usb/usb_<label>

using the numeric GID corresponding to the TOS allusers group.


Actual behavior

The USB disks are detected and displayed by TOS, but remain Unmounted.

StorageManager attempts RW and then RO mounting. Both commands contain

Code: Select all

gid=allusers

, which ntfs-3g rejects because the gid is not numeric.


Current workaround

As a temporary workaround I created a TOS startup task that discovers the USB filesystems by UUID and mounts them using the same ntfs-3g options with the numeric allusers GID.

This successfully mounts both drives read/write.

I would prefer to use the normal TOS USB automount functionality, so hopefully StorageManager can be corrected to resolve the allusers group to its numeric GID before calling ntfs-3g.

Please let me know if additional logs or testing would be useful.

[TMzethar]

Hi, I'm sorry you encountered this issue, and thank you very much for sharing your findings. I've forwarded them to the project team, and I hope they'll find them helpful.
You may want to consider downloading this new version of the Storage Manager app and manually uploading and installing it to resolve the issue.
https://download3.terra-master.com/Apps ... _amd64.deb