[Help] TOS 7.0.0804 - NTFS USB drives fail to mount - StorageManager uses invalid gid=allusers
Posted: 02 Aug 2026, 06:28
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:
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 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:
USB detection works correctly
Both disks and their NTFS partitions are detected:
TOS also remembers both volumes in:
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:
Neither attempt succeeds.
Reproducing the error manually
I created a temporary mountpoint and ran the same RO command being generated by StorageManager:
ntfs-3g immediately returns:
This appears to identify the reason both StorageManager mount attempts fail.
allusers group
On the TNAS:
Therefore the numeric GID on this system is:
Same mount succeeds with numeric GID
I repeated the same mount, changing only to :
The command completed successfully.
findmnt then confirmed:
So:
NTFS filesystem checks
I also checked both NTFS filesystems with ntfsfix in no-action mode before testing.
12 TB disk:
4 TB disk:
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:
StorageManager accepted both insert events successfully, but again generated the same ntfs-3g commands containing:
and both volumes remained unmounted.
Suspected cause
It appears StorageManager is passing the TOS group name:
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:
and using:
successfully mounts the same filesystem.
Expected behavior
When an NTFS USB disk is detected, StorageManager should automatically mount it under:
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, 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.
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=allusersI was able to reproduce the failure manually and then successfully mount the same filesystem by changing only this option from
Code: Select all
gid=allusersSystem / 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
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>
Code: Select all
/etc/tos/config/usb_mount_map.jsonStorageManager 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
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
Code: Select all
'gid' option needs a decimal value
allusers group
On the TNAS:
Code: Select all
$ getent group allusers
allusers:x:997:guest,admin,SysAdminTron
Code: Select all
997Same mount succeeds with numeric GID
I repeated the same mount, changing only
Code: Select all
gid=allusersCode: Select all
gid=997Code: Select all
/usr/bin/ntfs-3g -o ro,noatime,async,iocharset=utf8,gid=997,dmask=007 /dev/sdf2 /Volume1/@usb/test_PlexOffline
findmnt then confirmed:
Code: Select all
TARGET SOURCE FSTYPE OPTIONS
/Volume1/@usb/test_PlexOffline /dev/sdf2 fuseblk ro,noatime,...
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.
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.
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
Code: Select all
gid=allusersSuspected cause
It appears StorageManager is passing the TOS group name:
Code: Select all
gid=allusersntfs-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
Code: Select all
gid=997Expected behavior
When an NTFS USB disk is detected, StorageManager should automatically mount it under:
Code: Select all
/Volume1/@usb/usb_<label>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=allusersCurrent 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.