Write access to NTFS drives
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
Never had this problem before. The drives will not give me write access
Drives are ntfs.
Fstab was set on default, now tried rw option and nothing.
Using Manjaro.
How can I get write access to drives?
Those are the permissions at the mount point:
drwxr-xr-x 12 root root 4096 mar 30 03:23 Hitachi
drwxrwxrwx 1 root root 8192 mar 28 13:05 Tor
drwxrwxrwx 1 root root 4096 mar 28 13:05 WD
drwxrwxrwx 1 root root 4096 abr 10 01:10 Win10
fstab entries:
UUID=821840AA18409F53 /home/poldini/Desktop/Win10 ntfs auto,rw,noatime
0 2
UUID=E600C8DD00C8B5B9 /home/poldini/Desktop/WD ntfs
auto,rw,noatime 0 2
UUID=0356C5240C356E1A /home/poldini/Desktop/Torr
ntfs auto,rw,noatime 0 2
UUID=76222aac-470c-4d9d-97e4-f2cf0afeef4d
/home/poldini/Desktop/Hitachi ext4 auto,rw,noatime 0 2
mount output:
/dev/sdb2 on /home/poldini/Desktop/Win10 type fuseblk
(ro,nosuid,nodev,noatime,user_id=0,group_id=0,allow_other,blksize=4096)
/dev/sdc2 on /home/poldini/Desktop/WD type fuseblk
(ro,nosuid,nodev,noatime,user_id=0,group_id=0,allow_other,blksize=4096) [WD]
/dev/sde1 on /home/poldini/Desktop/Hitachi type ext4 (rw,noatime,data=ordered)
/dev/sda1 on /home/poldini/Desktop/Torr type fuseblk
(ro,nosuid,nodev,noatime,user_id=0,group_id=0,allow_other,blksize=4096)
filesystems fstab manjaro administration read-write
 |Â
show 1 more comment
up vote
1
down vote
favorite
Never had this problem before. The drives will not give me write access
Drives are ntfs.
Fstab was set on default, now tried rw option and nothing.
Using Manjaro.
How can I get write access to drives?
Those are the permissions at the mount point:
drwxr-xr-x 12 root root 4096 mar 30 03:23 Hitachi
drwxrwxrwx 1 root root 8192 mar 28 13:05 Tor
drwxrwxrwx 1 root root 4096 mar 28 13:05 WD
drwxrwxrwx 1 root root 4096 abr 10 01:10 Win10
fstab entries:
UUID=821840AA18409F53 /home/poldini/Desktop/Win10 ntfs auto,rw,noatime
0 2
UUID=E600C8DD00C8B5B9 /home/poldini/Desktop/WD ntfs
auto,rw,noatime 0 2
UUID=0356C5240C356E1A /home/poldini/Desktop/Torr
ntfs auto,rw,noatime 0 2
UUID=76222aac-470c-4d9d-97e4-f2cf0afeef4d
/home/poldini/Desktop/Hitachi ext4 auto,rw,noatime 0 2
mount output:
/dev/sdb2 on /home/poldini/Desktop/Win10 type fuseblk
(ro,nosuid,nodev,noatime,user_id=0,group_id=0,allow_other,blksize=4096)
/dev/sdc2 on /home/poldini/Desktop/WD type fuseblk
(ro,nosuid,nodev,noatime,user_id=0,group_id=0,allow_other,blksize=4096) [WD]
/dev/sde1 on /home/poldini/Desktop/Hitachi type ext4 (rw,noatime,data=ordered)
/dev/sda1 on /home/poldini/Desktop/Torr type fuseblk
(ro,nosuid,nodev,noatime,user_id=0,group_id=0,allow_other,blksize=4096)
filesystems fstab manjaro administration read-write
what are the permissions?
â Debian_yadav
Apr 10 at 8:13
drwxr-xr-x 12 root root 4096 mar 30 03:23 Hitachi drwxrwxrwx 1 root root 8192 mar 28 13:05 Tor drwxrwxrwx 1 root root 4096 mar 28 13:05 WD drwxrwxrwx 1 root root 4096 abr 10 01:10 Win10 Those are the permissions at the mount point.
â Leopoldini
Apr 10 at 8:21
Maybe the filesystems have been remounted R/O after a disk error? Are the SMART data OK?
â xenoid
Apr 10 at 8:38
1
Please edit your question and add all relevant information. Comments aren't meant for that.
â user252181
Apr 10 at 9:25
1
add the output ofmount
- the output should show whether they're mounted rw or ro. If they're read-only, a reboot would potentially bring the disk(s) back up as read-write based on your fstab. side note; mounting drives with 777 permissions is generally a bad idea..
â RobotJohnny
Apr 10 at 13:08
 |Â
show 1 more comment
up vote
1
down vote
favorite
up vote
1
down vote
favorite
Never had this problem before. The drives will not give me write access
Drives are ntfs.
Fstab was set on default, now tried rw option and nothing.
Using Manjaro.
How can I get write access to drives?
Those are the permissions at the mount point:
drwxr-xr-x 12 root root 4096 mar 30 03:23 Hitachi
drwxrwxrwx 1 root root 8192 mar 28 13:05 Tor
drwxrwxrwx 1 root root 4096 mar 28 13:05 WD
drwxrwxrwx 1 root root 4096 abr 10 01:10 Win10
fstab entries:
UUID=821840AA18409F53 /home/poldini/Desktop/Win10 ntfs auto,rw,noatime
0 2
UUID=E600C8DD00C8B5B9 /home/poldini/Desktop/WD ntfs
auto,rw,noatime 0 2
UUID=0356C5240C356E1A /home/poldini/Desktop/Torr
ntfs auto,rw,noatime 0 2
UUID=76222aac-470c-4d9d-97e4-f2cf0afeef4d
/home/poldini/Desktop/Hitachi ext4 auto,rw,noatime 0 2
mount output:
/dev/sdb2 on /home/poldini/Desktop/Win10 type fuseblk
(ro,nosuid,nodev,noatime,user_id=0,group_id=0,allow_other,blksize=4096)
/dev/sdc2 on /home/poldini/Desktop/WD type fuseblk
(ro,nosuid,nodev,noatime,user_id=0,group_id=0,allow_other,blksize=4096) [WD]
/dev/sde1 on /home/poldini/Desktop/Hitachi type ext4 (rw,noatime,data=ordered)
/dev/sda1 on /home/poldini/Desktop/Torr type fuseblk
(ro,nosuid,nodev,noatime,user_id=0,group_id=0,allow_other,blksize=4096)
filesystems fstab manjaro administration read-write
Never had this problem before. The drives will not give me write access
Drives are ntfs.
Fstab was set on default, now tried rw option and nothing.
Using Manjaro.
How can I get write access to drives?
Those are the permissions at the mount point:
drwxr-xr-x 12 root root 4096 mar 30 03:23 Hitachi
drwxrwxrwx 1 root root 8192 mar 28 13:05 Tor
drwxrwxrwx 1 root root 4096 mar 28 13:05 WD
drwxrwxrwx 1 root root 4096 abr 10 01:10 Win10
fstab entries:
UUID=821840AA18409F53 /home/poldini/Desktop/Win10 ntfs auto,rw,noatime
0 2
UUID=E600C8DD00C8B5B9 /home/poldini/Desktop/WD ntfs
auto,rw,noatime 0 2
UUID=0356C5240C356E1A /home/poldini/Desktop/Torr
ntfs auto,rw,noatime 0 2
UUID=76222aac-470c-4d9d-97e4-f2cf0afeef4d
/home/poldini/Desktop/Hitachi ext4 auto,rw,noatime 0 2
mount output:
/dev/sdb2 on /home/poldini/Desktop/Win10 type fuseblk
(ro,nosuid,nodev,noatime,user_id=0,group_id=0,allow_other,blksize=4096)
/dev/sdc2 on /home/poldini/Desktop/WD type fuseblk
(ro,nosuid,nodev,noatime,user_id=0,group_id=0,allow_other,blksize=4096) [WD]
/dev/sde1 on /home/poldini/Desktop/Hitachi type ext4 (rw,noatime,data=ordered)
/dev/sda1 on /home/poldini/Desktop/Torr type fuseblk
(ro,nosuid,nodev,noatime,user_id=0,group_id=0,allow_other,blksize=4096)
filesystems fstab manjaro administration read-write
edited Apr 10 at 19:44
asked Apr 10 at 8:01
Leopoldini
165
165
what are the permissions?
â Debian_yadav
Apr 10 at 8:13
drwxr-xr-x 12 root root 4096 mar 30 03:23 Hitachi drwxrwxrwx 1 root root 8192 mar 28 13:05 Tor drwxrwxrwx 1 root root 4096 mar 28 13:05 WD drwxrwxrwx 1 root root 4096 abr 10 01:10 Win10 Those are the permissions at the mount point.
â Leopoldini
Apr 10 at 8:21
Maybe the filesystems have been remounted R/O after a disk error? Are the SMART data OK?
â xenoid
Apr 10 at 8:38
1
Please edit your question and add all relevant information. Comments aren't meant for that.
â user252181
Apr 10 at 9:25
1
add the output ofmount
- the output should show whether they're mounted rw or ro. If they're read-only, a reboot would potentially bring the disk(s) back up as read-write based on your fstab. side note; mounting drives with 777 permissions is generally a bad idea..
â RobotJohnny
Apr 10 at 13:08
 |Â
show 1 more comment
what are the permissions?
â Debian_yadav
Apr 10 at 8:13
drwxr-xr-x 12 root root 4096 mar 30 03:23 Hitachi drwxrwxrwx 1 root root 8192 mar 28 13:05 Tor drwxrwxrwx 1 root root 4096 mar 28 13:05 WD drwxrwxrwx 1 root root 4096 abr 10 01:10 Win10 Those are the permissions at the mount point.
â Leopoldini
Apr 10 at 8:21
Maybe the filesystems have been remounted R/O after a disk error? Are the SMART data OK?
â xenoid
Apr 10 at 8:38
1
Please edit your question and add all relevant information. Comments aren't meant for that.
â user252181
Apr 10 at 9:25
1
add the output ofmount
- the output should show whether they're mounted rw or ro. If they're read-only, a reboot would potentially bring the disk(s) back up as read-write based on your fstab. side note; mounting drives with 777 permissions is generally a bad idea..
â RobotJohnny
Apr 10 at 13:08
what are the permissions?
â Debian_yadav
Apr 10 at 8:13
what are the permissions?
â Debian_yadav
Apr 10 at 8:13
drwxr-xr-x 12 root root 4096 mar 30 03:23 Hitachi drwxrwxrwx 1 root root 8192 mar 28 13:05 Tor drwxrwxrwx 1 root root 4096 mar 28 13:05 WD drwxrwxrwx 1 root root 4096 abr 10 01:10 Win10 Those are the permissions at the mount point.
â Leopoldini
Apr 10 at 8:21
drwxr-xr-x 12 root root 4096 mar 30 03:23 Hitachi drwxrwxrwx 1 root root 8192 mar 28 13:05 Tor drwxrwxrwx 1 root root 4096 mar 28 13:05 WD drwxrwxrwx 1 root root 4096 abr 10 01:10 Win10 Those are the permissions at the mount point.
â Leopoldini
Apr 10 at 8:21
Maybe the filesystems have been remounted R/O after a disk error? Are the SMART data OK?
â xenoid
Apr 10 at 8:38
Maybe the filesystems have been remounted R/O after a disk error? Are the SMART data OK?
â xenoid
Apr 10 at 8:38
1
1
Please edit your question and add all relevant information. Comments aren't meant for that.
â user252181
Apr 10 at 9:25
Please edit your question and add all relevant information. Comments aren't meant for that.
â user252181
Apr 10 at 9:25
1
1
add the output of
mount
- the output should show whether they're mounted rw or ro. If they're read-only, a reboot would potentially bring the disk(s) back up as read-write based on your fstab. side note; mounting drives with 777 permissions is generally a bad idea..â RobotJohnny
Apr 10 at 13:08
add the output of
mount
- the output should show whether they're mounted rw or ro. If they're read-only, a reboot would potentially bring the disk(s) back up as read-write based on your fstab. side note; mounting drives with 777 permissions is generally a bad idea..â RobotJohnny
Apr 10 at 13:08
 |Â
show 1 more comment
3 Answers
3
active
oldest
votes
up vote
1
down vote
I had suspected but wanted to see if there was a work around.
Windows cache features need to be turned of for the disks. Once I did that via windows all privileges were granted.
add a comment |Â
up vote
1
down vote
For me this was a problem and as correctly identified by @Leopoldini this is a problem with Windows Disk Write Caching. I have tested this with Windows 10 and Fedora and it worked for me.
Steps I followed were as below,
Win 10, first go to,
Device Manager -> Disk Drives
Then, select the disk you want to disable caching - right click -> Properties -> Policies -> Write-Caching policy
Uncheck "Enable write caching on the device"
That's it.. Reboot to Linux ( for me it is Fedora 28 ). Now you will see the disk got mounted with "rw" permission.
add a comment |Â
up vote
1
down vote
The Linux NTFS kernel module (CONFIG_NTFS_FS) provides read-only access to NTFS volumes; It does not support read-write access. To get read-write access you need either:
- Read-write support enabled (CONFIG_NTFS_RW, not recommended)
- Use the FUSE-based NTFS-3G module (recommended)
Why is the built-in module not recommended?
[CONFIG_NTFS_RW] enables the partial, but safe, write support in the NTFS driver.
The only supported operation is overwriting existing files, without
changing the file length. No file or directory creation, deletion or
renaming is possible. Note only non-resident files can be written to
so you may find that some very small files (<500 bytes or so) cannot
be written to. - https://cateee.net/lkddb/web-lkddb/NTFS_RW.html
Assuming you have NTFS-3G installed, to use the module replace ntfs
with ntfs-3g
in your /etc/fstab
UUID=821840AA18409F53 /home/poldini/Desktop/Win10 ntfs-3g auto,rw,noatime
0 2
UUID=E600C8DD00C8B5B9 /home/poldini/Desktop/WD ntfs-3g
auto,rw,noatime 0 2
UUID=0356C5240C356E1A /home/poldini/Desktop/Torr
ntfs-3g auto,rw,noatime 0 2
UUID=76222aac-470c-4d9d-97e4-f2cf0afeef4d
/home/poldini/Desktop/Hitachi ext4 auto,rw,noatime 0 2
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
I had suspected but wanted to see if there was a work around.
Windows cache features need to be turned of for the disks. Once I did that via windows all privileges were granted.
add a comment |Â
up vote
1
down vote
I had suspected but wanted to see if there was a work around.
Windows cache features need to be turned of for the disks. Once I did that via windows all privileges were granted.
add a comment |Â
up vote
1
down vote
up vote
1
down vote
I had suspected but wanted to see if there was a work around.
Windows cache features need to be turned of for the disks. Once I did that via windows all privileges were granted.
I had suspected but wanted to see if there was a work around.
Windows cache features need to be turned of for the disks. Once I did that via windows all privileges were granted.
answered Apr 10 at 19:44
Leopoldini
165
165
add a comment |Â
add a comment |Â
up vote
1
down vote
For me this was a problem and as correctly identified by @Leopoldini this is a problem with Windows Disk Write Caching. I have tested this with Windows 10 and Fedora and it worked for me.
Steps I followed were as below,
Win 10, first go to,
Device Manager -> Disk Drives
Then, select the disk you want to disable caching - right click -> Properties -> Policies -> Write-Caching policy
Uncheck "Enable write caching on the device"
That's it.. Reboot to Linux ( for me it is Fedora 28 ). Now you will see the disk got mounted with "rw" permission.
add a comment |Â
up vote
1
down vote
For me this was a problem and as correctly identified by @Leopoldini this is a problem with Windows Disk Write Caching. I have tested this with Windows 10 and Fedora and it worked for me.
Steps I followed were as below,
Win 10, first go to,
Device Manager -> Disk Drives
Then, select the disk you want to disable caching - right click -> Properties -> Policies -> Write-Caching policy
Uncheck "Enable write caching on the device"
That's it.. Reboot to Linux ( for me it is Fedora 28 ). Now you will see the disk got mounted with "rw" permission.
add a comment |Â
up vote
1
down vote
up vote
1
down vote
For me this was a problem and as correctly identified by @Leopoldini this is a problem with Windows Disk Write Caching. I have tested this with Windows 10 and Fedora and it worked for me.
Steps I followed were as below,
Win 10, first go to,
Device Manager -> Disk Drives
Then, select the disk you want to disable caching - right click -> Properties -> Policies -> Write-Caching policy
Uncheck "Enable write caching on the device"
That's it.. Reboot to Linux ( for me it is Fedora 28 ). Now you will see the disk got mounted with "rw" permission.
For me this was a problem and as correctly identified by @Leopoldini this is a problem with Windows Disk Write Caching. I have tested this with Windows 10 and Fedora and it worked for me.
Steps I followed were as below,
Win 10, first go to,
Device Manager -> Disk Drives
Then, select the disk you want to disable caching - right click -> Properties -> Policies -> Write-Caching policy
Uncheck "Enable write caching on the device"
That's it.. Reboot to Linux ( for me it is Fedora 28 ). Now you will see the disk got mounted with "rw" permission.
answered May 31 at 13:55
NIK
15116
15116
add a comment |Â
add a comment |Â
up vote
1
down vote
The Linux NTFS kernel module (CONFIG_NTFS_FS) provides read-only access to NTFS volumes; It does not support read-write access. To get read-write access you need either:
- Read-write support enabled (CONFIG_NTFS_RW, not recommended)
- Use the FUSE-based NTFS-3G module (recommended)
Why is the built-in module not recommended?
[CONFIG_NTFS_RW] enables the partial, but safe, write support in the NTFS driver.
The only supported operation is overwriting existing files, without
changing the file length. No file or directory creation, deletion or
renaming is possible. Note only non-resident files can be written to
so you may find that some very small files (<500 bytes or so) cannot
be written to. - https://cateee.net/lkddb/web-lkddb/NTFS_RW.html
Assuming you have NTFS-3G installed, to use the module replace ntfs
with ntfs-3g
in your /etc/fstab
UUID=821840AA18409F53 /home/poldini/Desktop/Win10 ntfs-3g auto,rw,noatime
0 2
UUID=E600C8DD00C8B5B9 /home/poldini/Desktop/WD ntfs-3g
auto,rw,noatime 0 2
UUID=0356C5240C356E1A /home/poldini/Desktop/Torr
ntfs-3g auto,rw,noatime 0 2
UUID=76222aac-470c-4d9d-97e4-f2cf0afeef4d
/home/poldini/Desktop/Hitachi ext4 auto,rw,noatime 0 2
add a comment |Â
up vote
1
down vote
The Linux NTFS kernel module (CONFIG_NTFS_FS) provides read-only access to NTFS volumes; It does not support read-write access. To get read-write access you need either:
- Read-write support enabled (CONFIG_NTFS_RW, not recommended)
- Use the FUSE-based NTFS-3G module (recommended)
Why is the built-in module not recommended?
[CONFIG_NTFS_RW] enables the partial, but safe, write support in the NTFS driver.
The only supported operation is overwriting existing files, without
changing the file length. No file or directory creation, deletion or
renaming is possible. Note only non-resident files can be written to
so you may find that some very small files (<500 bytes or so) cannot
be written to. - https://cateee.net/lkddb/web-lkddb/NTFS_RW.html
Assuming you have NTFS-3G installed, to use the module replace ntfs
with ntfs-3g
in your /etc/fstab
UUID=821840AA18409F53 /home/poldini/Desktop/Win10 ntfs-3g auto,rw,noatime
0 2
UUID=E600C8DD00C8B5B9 /home/poldini/Desktop/WD ntfs-3g
auto,rw,noatime 0 2
UUID=0356C5240C356E1A /home/poldini/Desktop/Torr
ntfs-3g auto,rw,noatime 0 2
UUID=76222aac-470c-4d9d-97e4-f2cf0afeef4d
/home/poldini/Desktop/Hitachi ext4 auto,rw,noatime 0 2
add a comment |Â
up vote
1
down vote
up vote
1
down vote
The Linux NTFS kernel module (CONFIG_NTFS_FS) provides read-only access to NTFS volumes; It does not support read-write access. To get read-write access you need either:
- Read-write support enabled (CONFIG_NTFS_RW, not recommended)
- Use the FUSE-based NTFS-3G module (recommended)
Why is the built-in module not recommended?
[CONFIG_NTFS_RW] enables the partial, but safe, write support in the NTFS driver.
The only supported operation is overwriting existing files, without
changing the file length. No file or directory creation, deletion or
renaming is possible. Note only non-resident files can be written to
so you may find that some very small files (<500 bytes or so) cannot
be written to. - https://cateee.net/lkddb/web-lkddb/NTFS_RW.html
Assuming you have NTFS-3G installed, to use the module replace ntfs
with ntfs-3g
in your /etc/fstab
UUID=821840AA18409F53 /home/poldini/Desktop/Win10 ntfs-3g auto,rw,noatime
0 2
UUID=E600C8DD00C8B5B9 /home/poldini/Desktop/WD ntfs-3g
auto,rw,noatime 0 2
UUID=0356C5240C356E1A /home/poldini/Desktop/Torr
ntfs-3g auto,rw,noatime 0 2
UUID=76222aac-470c-4d9d-97e4-f2cf0afeef4d
/home/poldini/Desktop/Hitachi ext4 auto,rw,noatime 0 2
The Linux NTFS kernel module (CONFIG_NTFS_FS) provides read-only access to NTFS volumes; It does not support read-write access. To get read-write access you need either:
- Read-write support enabled (CONFIG_NTFS_RW, not recommended)
- Use the FUSE-based NTFS-3G module (recommended)
Why is the built-in module not recommended?
[CONFIG_NTFS_RW] enables the partial, but safe, write support in the NTFS driver.
The only supported operation is overwriting existing files, without
changing the file length. No file or directory creation, deletion or
renaming is possible. Note only non-resident files can be written to
so you may find that some very small files (<500 bytes or so) cannot
be written to. - https://cateee.net/lkddb/web-lkddb/NTFS_RW.html
Assuming you have NTFS-3G installed, to use the module replace ntfs
with ntfs-3g
in your /etc/fstab
UUID=821840AA18409F53 /home/poldini/Desktop/Win10 ntfs-3g auto,rw,noatime
0 2
UUID=E600C8DD00C8B5B9 /home/poldini/Desktop/WD ntfs-3g
auto,rw,noatime 0 2
UUID=0356C5240C356E1A /home/poldini/Desktop/Torr
ntfs-3g auto,rw,noatime 0 2
UUID=76222aac-470c-4d9d-97e4-f2cf0afeef4d
/home/poldini/Desktop/Hitachi ext4 auto,rw,noatime 0 2
answered May 31 at 16:58
Emmanuel Rosa
2,1951410
2,1951410
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f436712%2fwrite-access-to-ntfs-drives%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
what are the permissions?
â Debian_yadav
Apr 10 at 8:13
drwxr-xr-x 12 root root 4096 mar 30 03:23 Hitachi drwxrwxrwx 1 root root 8192 mar 28 13:05 Tor drwxrwxrwx 1 root root 4096 mar 28 13:05 WD drwxrwxrwx 1 root root 4096 abr 10 01:10 Win10 Those are the permissions at the mount point.
â Leopoldini
Apr 10 at 8:21
Maybe the filesystems have been remounted R/O after a disk error? Are the SMART data OK?
â xenoid
Apr 10 at 8:38
1
Please edit your question and add all relevant information. Comments aren't meant for that.
â user252181
Apr 10 at 9:25
1
add the output of
mount
- the output should show whether they're mounted rw or ro. If they're read-only, a reboot would potentially bring the disk(s) back up as read-write based on your fstab. side note; mounting drives with 777 permissions is generally a bad idea..â RobotJohnny
Apr 10 at 13:08