How to copy files and folders from a usb ntfs filesystem to internal ext4 without importing permissions?
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
I have a USB disk that I use to synchronize data between computers with different operating systems (currently using a nice GUI utility called FreeFileSync), and its format is NTFS (which is preferable to FAT32 due to better support for long filenames as well as use of upper and lowercase).
When I copy files from it to my Linux computer, unfortunately I get all the files executable (as well as writable and readable) by all, which is a problem.
How can I get around this issue?
Creating a fstab entry which will only apply to that USB ntfs disk (or using a manual command, i.e. sudo mount ...) to mount it with such access permissions like 644, but also giving me full access on that usb disk (i.e. not having root ownership)?
Using a manual command (e.g. instead of Nautilus file manager) to copy (preferably synchronize) files without importing ntfs permissions? I tried rsync -rltgoD /source/ /target/ omitting -p (preserve permissions) without success.
I would ideally prefer a GUI sync tool (like FreeFileSync) which offers this option but I guess there's none out there.
If theres is no such GUI tool, I would probably prefer something like a quick manual tweak which will work once and for all in this sync scenario.
Otherwise, the option I have available now seems continuing with the syncing/copying tasks as usual with FreeFileSync, and then running a terminal command like find . -type f -exec chmod -R 644 ; to fix this issue caused by ntfs filesytem treating all readable permissions also as executable.
permissions file-copy synchronization
asked Oct 28 '17 at 17:10
Sadi
220111
add a comment |Â
up vote
0
down vote
favorite
I have a USB disk that I use to synchronize data between computers with different operating systems (currently using a nice GUI utility called FreeFileSync), and its format is NTFS (which is preferable to FAT32 due to better support for long filenames as well as use of upper and lowercase).
When I copy files from it to my Linux computer, unfortunately I get all the files executable (as well as writable and readable) by all, which is a problem.
How can I get around this issue?
Creating a fstab entry which will only apply to that USB ntfs disk (or using a manual command, i.e. sudo mount ...) to mount it with such access permissions like 644, but also giving me full access on that usb disk (i.e. not having root ownership)?
Using a manual command (e.g. instead of Nautilus file manager) to copy (preferably synchronize) files without importing ntfs permissions? I tried rsync -rltgoD /source/ /target/ omitting -p (preserve permissions) without success.
I would ideally prefer a GUI sync tool (like FreeFileSync) which offers this option but I guess there's none out there.
If theres is no such GUI tool, I would probably prefer something like a quick manual tweak which will work once and for all in this sync scenario.
Otherwise, the option I have available now seems continuing with the syncing/copying tasks as usual with FreeFileSync, and then running a terminal command like find . -type f -exec chmod -R 644 ; to fix this issue caused by ntfs filesytem treating all readable permissions also as executable.
permissions file-copy synchronization
asked Oct 28 '17 at 17:10
Sadi
220111
I don't have a full answer, but my best suggestion at this point would be to create an archive on the NTFS partition, such as a tarball, which can preserve ownerships & permissions internally.
– Jeff Schaller
Oct 28 '17 at 23:28
@JeffSchaller: I’m not sure, but I guess that this problem comes from the fact that Windows conflates read access and execute access — the default permission when you add a user to an ACL is “Read & Executeâ€Â, and you can’t set “Modify†permission without including execute access without using the “Advanced†dialog.  So most files have execute access in the Windows scheme; tar would probably “preserve†that access by setting the--xbit.
– G-Man
Oct 29 '17 at 3:35
@Sadi: People are voting to close this question as “primarily opinion-basedâ€Â, probably because you’re asking for the best way to do something.  You may be able to fix this by changing the question to ask for a good way, and/or specifying objective criteria by which the quality of competing answers is to be evaluated.
– G-Man
Oct 29 '17 at 3:42
@G-Man: Thanks, it seems I should better improve the question a bit...
– Sadi
Oct 29 '17 at 7:38
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I have a USB disk that I use to synchronize data between computers with different operating systems (currently using a nice GUI utility called FreeFileSync), and its format is NTFS (which is preferable to FAT32 due to better support for long filenames as well as use of upper and lowercase).
When I copy files from it to my Linux computer, unfortunately I get all the files executable (as well as writable and readable) by all, which is a problem.
How can I get around this issue?
Creating a fstab entry which will only apply to that USB ntfs disk (or using a manual command, i.e. sudo mount ...) to mount it with such access permissions like 644, but also giving me full access on that usb disk (i.e. not having root ownership)?
Using a manual command (e.g. instead of Nautilus file manager) to copy (preferably synchronize) files without importing ntfs permissions? I tried rsync -rltgoD /source/ /target/ omitting -p (preserve permissions) without success.
I would ideally prefer a GUI sync tool (like FreeFileSync) which offers this option but I guess there's none out there.
If theres is no such GUI tool, I would probably prefer something like a quick manual tweak which will work once and for all in this sync scenario.
Otherwise, the option I have available now seems continuing with the syncing/copying tasks as usual with FreeFileSync, and then running a terminal command like find . -type f -exec chmod -R 644 ; to fix this issue caused by ntfs filesytem treating all readable permissions also as executable.
permissions file-copy synchronization
asked Oct 28 '17 at 17:10
Sadi
220111
I have a USB disk that I use to synchronize data between computers with different operating systems (currently using a nice GUI utility called FreeFileSync), and its format is NTFS (which is preferable to FAT32 due to better support for long filenames as well as use of upper and lowercase).
When I copy files from it to my Linux computer, unfortunately I get all the files executable (as well as writable and readable) by all, which is a problem.
How can I get around this issue?
Creating a fstab entry which will only apply to that USB ntfs disk (or using a manual command, i.e. sudo mount ...) to mount it with such access permissions like 644, but also giving me full access on that usb disk (i.e. not having root ownership)?
Using a manual command (e.g. instead of Nautilus file manager) to copy (preferably synchronize) files without importing ntfs permissions? I tried rsync -rltgoD /source/ /target/ omitting -p (preserve permissions) without success.
I would ideally prefer a GUI sync tool (like FreeFileSync) which offers this option but I guess there's none out there.
If theres is no such GUI tool, I would probably prefer something like a quick manual tweak which will work once and for all in this sync scenario.
Otherwise, the option I have available now seems continuing with the syncing/copying tasks as usual with FreeFileSync, and then running a terminal command like find . -type f -exec chmod -R 644 ; to fix this issue caused by ntfs filesytem treating all readable permissions also as executable.
permissions file-copy synchronization
asked Oct 28 '17 at 17:10
Sadi
220111
edited Nov 1 '17 at 14:34
asked Oct 28 '17 at 17:10
Sadi
220111
asked Oct 28 '17 at 17:10
Sadi
220111
asked Oct 28 '17 at 17:10
Sadi
220111
220111
I don't have a full answer, but my best suggestion at this point would be to create an archive on the NTFS partition, such as a tarball, which can preserve ownerships & permissions internally.
– Jeff Schaller
Oct 28 '17 at 23:28
@JeffSchaller: I’m not sure, but I guess that this problem comes from the fact that Windows conflates read access and execute access — the default permission when you add a user to an ACL is “Read & Executeâ€Â, and you can’t set “Modify†permission without including execute access without using the “Advanced†dialog.  So most files have execute access in the Windows scheme; tar would probably “preserve†that access by setting the--xbit.
– G-Man
Oct 29 '17 at 3:35
@Sadi: People are voting to close this question as “primarily opinion-basedâ€Â, probably because you’re asking for the best way to do something.  You may be able to fix this by changing the question to ask for a good way, and/or specifying objective criteria by which the quality of competing answers is to be evaluated.
– G-Man
Oct 29 '17 at 3:42
@G-Man: Thanks, it seems I should better improve the question a bit...
– Sadi
Oct 29 '17 at 7:38
add a comment |Â
I don't have a full answer, but my best suggestion at this point would be to create an archive on the NTFS partition, such as a tarball, which can preserve ownerships & permissions internally.
– Jeff Schaller
Oct 28 '17 at 23:28
@JeffSchaller: I’m not sure, but I guess that this problem comes from the fact that Windows conflates read access and execute access — the default permission when you add a user to an ACL is “Read & Executeâ€Â, and you can’t set “Modify†permission without including execute access without using the “Advanced†dialog.  So most files have execute access in the Windows scheme; tar would probably “preserve†that access by setting the--xbit.
– G-Man
Oct 29 '17 at 3:35
@Sadi: People are voting to close this question as “primarily opinion-basedâ€Â, probably because you’re asking for the best way to do something.  You may be able to fix this by changing the question to ask for a good way, and/or specifying objective criteria by which the quality of competing answers is to be evaluated.
– G-Man
Oct 29 '17 at 3:42
@G-Man: Thanks, it seems I should better improve the question a bit...
– Sadi
Oct 29 '17 at 7:38
I don't have a full answer, but my best suggestion at this point would be to create an archive on the NTFS partition, such as a tarball, which can preserve ownerships & permissions internally.
– Jeff Schaller
Oct 28 '17 at 23:28
I don't have a full answer, but my best suggestion at this point would be to create an archive on the NTFS partition, such as a tarball, which can preserve ownerships & permissions internally.
– Jeff Schaller
Oct 28 '17 at 23:28
@JeffSchaller: I’m not sure, but I guess that this problem comes from the fact that Windows conflates read access and execute access — the default permission when you add a user to an ACL is “Read & Executeâ€Â, and you can’t set “Modify†permission without including execute access without using the “Advanced†dialog.  So most files have execute access in the Windows scheme; tar would probably “preserve†that access by setting the
--x bit.– G-Man
Oct 29 '17 at 3:35
@JeffSchaller: I’m not sure, but I guess that this problem comes from the fact that Windows conflates read access and execute access — the default permission when you add a user to an ACL is “Read & Executeâ€Â, and you can’t set “Modify†permission without including execute access without using the “Advanced†dialog.  So most files have execute access in the Windows scheme; tar would probably “preserve†that access by setting the
--x bit.– G-Man
Oct 29 '17 at 3:35
@Sadi: People are voting to close this question as “primarily opinion-basedâ€Â, probably because you’re asking for the best way to do something.  You may be able to fix this by changing the question to ask for a good way, and/or specifying objective criteria by which the quality of competing answers is to be evaluated.
– G-Man
Oct 29 '17 at 3:42
@Sadi: People are voting to close this question as “primarily opinion-basedâ€Â, probably because you’re asking for the best way to do something.  You may be able to fix this by changing the question to ask for a good way, and/or specifying objective criteria by which the quality of competing answers is to be evaluated.
– G-Man
Oct 29 '17 at 3:42
@G-Man: Thanks, it seems I should better improve the question a bit...
– Sadi
Oct 29 '17 at 7:38
@G-Man: Thanks, it seems I should better improve the question a bit...
– Sadi
Oct 29 '17 at 7:38
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
3
down vote
This is a very common question surely a duplicate.
When you mount NTFS, you can set the file permissions - not at file level.sudo mount -t ntfs -o rw,auto,user,fmask=0133,dmask=0000 /dev/whatever /mnt/whatever
If you put a correct line in /etc/fstab, you can do GUI totally.dmask is for directory mask (777 - mask), fmask is for file mask (now 0777-0133 = 0644).
Meaning of numbers are:
- 0(special NTFS does not use IMO)
- 6(Owner rihts)
- 4(group right)
- 4(anybody else rights).
Meaning of digits: (you have to add these together to have multiple rights)
- 4 - read right
- 2 - write right
- 1 - execute right
Directories has to be executalble to able to enter it.
IF you want to retain "auto mount" functionality, but want to change file permission, write an appropriate line in /etc/fstab, like:UUID=02C8AE4FC8AE40B1 /mnt/usbntfs ntfs-3g fmask=0111 0 1
Meanings:
- UUID : your unique identifier of the disk. You can check with
sudo blkid - 2nd parameter is the place where system would automount (unfortunately this subdirectory will not be deleted after USB removal).
- 3rd is the filesystem type
- 4rd paramter is the flags you want to change (now we only inhibit execute bits of files)
- 5th and 6th parameters are not relevant here, just put
0 1
Other parts of the question:
It is possible to "play" with the rights and ownership in NTFS partition under linux, if you add permissions in the parameters, likeUUID=02C8AE4FC8AE40B1 /mnt/usbntfs ntfs-3g permissions 0 1
Note: This is incompatible with fmask and dmask.
However I do not know how you see or how this effects the rights under Windows.
answered Oct 28 '17 at 21:18
V-Mark
25616
+1 and thanks a lot for this. But it seems I might have problems in writing to that USB disk during my sync operation although this solves the copying aspect of the problem (sorry, I should have it clearer). Isn't there a way of changing how the system automatically mounts such a USB disk? In that case ownership belongs to the user but unfortunately access permissions are not as I would like... Maybe you can suggest this also as a fstab entry in such a way that it will only apply to that particular USB disk, using UID?
– Sadi
Oct 29 '17 at 8:18
True. You originally mentioned this is an USB disk. I edited my answer how Ubuntu behaves with automount and fstab entries are existing.
– V-Mark
Oct 29 '17 at 16:41
Thanks. However, it seems fstab entry (a) requires the presence of that filesystem/partiton/disk during the boot process, therefore, is not useful for removable drives, and (b) results in root ownership of the mounted drive, although permissions are OK, which prevents making any changes there. It seems using the present automount feature, and at the end issuing a command to modify rwx permissions seems to be the only solution available. Is that right?
– Sadi
Oct 30 '17 at 7:54
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
This is a very common question surely a duplicate.
When you mount NTFS, you can set the file permissions - not at file level.sudo mount -t ntfs -o rw,auto,user,fmask=0133,dmask=0000 /dev/whatever /mnt/whatever
If you put a correct line in /etc/fstab, you can do GUI totally.dmask is for directory mask (777 - mask), fmask is for file mask (now 0777-0133 = 0644).
Meaning of numbers are:
- 0(special NTFS does not use IMO)
- 6(Owner rihts)
- 4(group right)
- 4(anybody else rights).
Meaning of digits: (you have to add these together to have multiple rights)
- 4 - read right
- 2 - write right
- 1 - execute right
Directories has to be executalble to able to enter it.
IF you want to retain "auto mount" functionality, but want to change file permission, write an appropriate line in /etc/fstab, like:UUID=02C8AE4FC8AE40B1 /mnt/usbntfs ntfs-3g fmask=0111 0 1
Meanings:
- UUID : your unique identifier of the disk. You can check with
sudo blkid - 2nd parameter is the place where system would automount (unfortunately this subdirectory will not be deleted after USB removal).
- 3rd is the filesystem type
- 4rd paramter is the flags you want to change (now we only inhibit execute bits of files)
- 5th and 6th parameters are not relevant here, just put
0 1
Other parts of the question:
It is possible to "play" with the rights and ownership in NTFS partition under linux, if you add permissions in the parameters, likeUUID=02C8AE4FC8AE40B1 /mnt/usbntfs ntfs-3g permissions 0 1
Note: This is incompatible with fmask and dmask.
However I do not know how you see or how this effects the rights under Windows.
answered Oct 28 '17 at 21:18
V-Mark
25616
+1 and thanks a lot for this. But it seems I might have problems in writing to that USB disk during my sync operation although this solves the copying aspect of the problem (sorry, I should have it clearer). Isn't there a way of changing how the system automatically mounts such a USB disk? In that case ownership belongs to the user but unfortunately access permissions are not as I would like... Maybe you can suggest this also as a fstab entry in such a way that it will only apply to that particular USB disk, using UID?
– Sadi
Oct 29 '17 at 8:18
True. You originally mentioned this is an USB disk. I edited my answer how Ubuntu behaves with automount and fstab entries are existing.
– V-Mark
Oct 29 '17 at 16:41
Thanks. However, it seems fstab entry (a) requires the presence of that filesystem/partiton/disk during the boot process, therefore, is not useful for removable drives, and (b) results in root ownership of the mounted drive, although permissions are OK, which prevents making any changes there. It seems using the present automount feature, and at the end issuing a command to modify rwx permissions seems to be the only solution available. Is that right?
– Sadi
Oct 30 '17 at 7:54
add a comment |Â
up vote
3
down vote
This is a very common question surely a duplicate.
When you mount NTFS, you can set the file permissions - not at file level.sudo mount -t ntfs -o rw,auto,user,fmask=0133,dmask=0000 /dev/whatever /mnt/whatever
If you put a correct line in /etc/fstab, you can do GUI totally.dmask is for directory mask (777 - mask), fmask is for file mask (now 0777-0133 = 0644).
Meaning of numbers are:
- 0(special NTFS does not use IMO)
- 6(Owner rihts)
- 4(group right)
- 4(anybody else rights).
Meaning of digits: (you have to add these together to have multiple rights)
- 4 - read right
- 2 - write right
- 1 - execute right
Directories has to be executalble to able to enter it.
IF you want to retain "auto mount" functionality, but want to change file permission, write an appropriate line in /etc/fstab, like:UUID=02C8AE4FC8AE40B1 /mnt/usbntfs ntfs-3g fmask=0111 0 1
Meanings:
- UUID : your unique identifier of the disk. You can check with
sudo blkid - 2nd parameter is the place where system would automount (unfortunately this subdirectory will not be deleted after USB removal).
- 3rd is the filesystem type
- 4rd paramter is the flags you want to change (now we only inhibit execute bits of files)
- 5th and 6th parameters are not relevant here, just put
0 1
Other parts of the question:
It is possible to "play" with the rights and ownership in NTFS partition under linux, if you add permissions in the parameters, likeUUID=02C8AE4FC8AE40B1 /mnt/usbntfs ntfs-3g permissions 0 1
Note: This is incompatible with fmask and dmask.
However I do not know how you see or how this effects the rights under Windows.
answered Oct 28 '17 at 21:18
V-Mark
25616
+1 and thanks a lot for this. But it seems I might have problems in writing to that USB disk during my sync operation although this solves the copying aspect of the problem (sorry, I should have it clearer). Isn't there a way of changing how the system automatically mounts such a USB disk? In that case ownership belongs to the user but unfortunately access permissions are not as I would like... Maybe you can suggest this also as a fstab entry in such a way that it will only apply to that particular USB disk, using UID?
– Sadi
Oct 29 '17 at 8:18
True. You originally mentioned this is an USB disk. I edited my answer how Ubuntu behaves with automount and fstab entries are existing.
– V-Mark
Oct 29 '17 at 16:41
Thanks. However, it seems fstab entry (a) requires the presence of that filesystem/partiton/disk during the boot process, therefore, is not useful for removable drives, and (b) results in root ownership of the mounted drive, although permissions are OK, which prevents making any changes there. It seems using the present automount feature, and at the end issuing a command to modify rwx permissions seems to be the only solution available. Is that right?
– Sadi
Oct 30 '17 at 7:54
add a comment |Â
up vote
3
down vote
up vote
3
down vote
This is a very common question surely a duplicate.
When you mount NTFS, you can set the file permissions - not at file level.sudo mount -t ntfs -o rw,auto,user,fmask=0133,dmask=0000 /dev/whatever /mnt/whatever
If you put a correct line in /etc/fstab, you can do GUI totally.dmask is for directory mask (777 - mask), fmask is for file mask (now 0777-0133 = 0644).
Meaning of numbers are:
- 0(special NTFS does not use IMO)
- 6(Owner rihts)
- 4(group right)
- 4(anybody else rights).
Meaning of digits: (you have to add these together to have multiple rights)
- 4 - read right
- 2 - write right
- 1 - execute right
Directories has to be executalble to able to enter it.
IF you want to retain "auto mount" functionality, but want to change file permission, write an appropriate line in /etc/fstab, like:UUID=02C8AE4FC8AE40B1 /mnt/usbntfs ntfs-3g fmask=0111 0 1
Meanings:
- UUID : your unique identifier of the disk. You can check with
sudo blkid - 2nd parameter is the place where system would automount (unfortunately this subdirectory will not be deleted after USB removal).
- 3rd is the filesystem type
- 4rd paramter is the flags you want to change (now we only inhibit execute bits of files)
- 5th and 6th parameters are not relevant here, just put
0 1
Other parts of the question:
It is possible to "play" with the rights and ownership in NTFS partition under linux, if you add permissions in the parameters, likeUUID=02C8AE4FC8AE40B1 /mnt/usbntfs ntfs-3g permissions 0 1
Note: This is incompatible with fmask and dmask.
However I do not know how you see or how this effects the rights under Windows.
answered Oct 28 '17 at 21:18
V-Mark
25616
This is a very common question surely a duplicate.
When you mount NTFS, you can set the file permissions - not at file level.sudo mount -t ntfs -o rw,auto,user,fmask=0133,dmask=0000 /dev/whatever /mnt/whatever
If you put a correct line in /etc/fstab, you can do GUI totally.dmask is for directory mask (777 - mask), fmask is for file mask (now 0777-0133 = 0644).
Meaning of numbers are:
- 0(special NTFS does not use IMO)
- 6(Owner rihts)
- 4(group right)
- 4(anybody else rights).
Meaning of digits: (you have to add these together to have multiple rights)
- 4 - read right
- 2 - write right
- 1 - execute right
Directories has to be executalble to able to enter it.
IF you want to retain "auto mount" functionality, but want to change file permission, write an appropriate line in /etc/fstab, like:UUID=02C8AE4FC8AE40B1 /mnt/usbntfs ntfs-3g fmask=0111 0 1
Meanings:
- UUID : your unique identifier of the disk. You can check with
sudo blkid - 2nd parameter is the place where system would automount (unfortunately this subdirectory will not be deleted after USB removal).
- 3rd is the filesystem type
- 4rd paramter is the flags you want to change (now we only inhibit execute bits of files)
- 5th and 6th parameters are not relevant here, just put
0 1
Other parts of the question:
It is possible to "play" with the rights and ownership in NTFS partition under linux, if you add permissions in the parameters, likeUUID=02C8AE4FC8AE40B1 /mnt/usbntfs ntfs-3g permissions 0 1
Note: This is incompatible with fmask and dmask.
However I do not know how you see or how this effects the rights under Windows.
answered Oct 28 '17 at 21:18
V-Mark
25616
edited Oct 29 '17 at 18:04
answered Oct 28 '17 at 21:18
V-Mark
25616
answered Oct 28 '17 at 21:18
V-Mark
25616
answered Oct 28 '17 at 21:18
V-Mark
25616
25616
+1 and thanks a lot for this. But it seems I might have problems in writing to that USB disk during my sync operation although this solves the copying aspect of the problem (sorry, I should have it clearer). Isn't there a way of changing how the system automatically mounts such a USB disk? In that case ownership belongs to the user but unfortunately access permissions are not as I would like... Maybe you can suggest this also as a fstab entry in such a way that it will only apply to that particular USB disk, using UID?
– Sadi
Oct 29 '17 at 8:18
True. You originally mentioned this is an USB disk. I edited my answer how Ubuntu behaves with automount and fstab entries are existing.
– V-Mark
Oct 29 '17 at 16:41
Thanks. However, it seems fstab entry (a) requires the presence of that filesystem/partiton/disk during the boot process, therefore, is not useful for removable drives, and (b) results in root ownership of the mounted drive, although permissions are OK, which prevents making any changes there. It seems using the present automount feature, and at the end issuing a command to modify rwx permissions seems to be the only solution available. Is that right?
– Sadi
Oct 30 '17 at 7:54
add a comment |Â
+1 and thanks a lot for this. But it seems I might have problems in writing to that USB disk during my sync operation although this solves the copying aspect of the problem (sorry, I should have it clearer). Isn't there a way of changing how the system automatically mounts such a USB disk? In that case ownership belongs to the user but unfortunately access permissions are not as I would like... Maybe you can suggest this also as a fstab entry in such a way that it will only apply to that particular USB disk, using UID?
– Sadi
Oct 29 '17 at 8:18
True. You originally mentioned this is an USB disk. I edited my answer how Ubuntu behaves with automount and fstab entries are existing.
– V-Mark
Oct 29 '17 at 16:41
Thanks. However, it seems fstab entry (a) requires the presence of that filesystem/partiton/disk during the boot process, therefore, is not useful for removable drives, and (b) results in root ownership of the mounted drive, although permissions are OK, which prevents making any changes there. It seems using the present automount feature, and at the end issuing a command to modify rwx permissions seems to be the only solution available. Is that right?
– Sadi
Oct 30 '17 at 7:54
+1 and thanks a lot for this. But it seems I might have problems in writing to that USB disk during my sync operation although this solves the copying aspect of the problem (sorry, I should have it clearer). Isn't there a way of changing how the system automatically mounts such a USB disk? In that case ownership belongs to the user but unfortunately access permissions are not as I would like... Maybe you can suggest this also as a fstab entry in such a way that it will only apply to that particular USB disk, using UID?
– Sadi
Oct 29 '17 at 8:18
+1 and thanks a lot for this. But it seems I might have problems in writing to that USB disk during my sync operation although this solves the copying aspect of the problem (sorry, I should have it clearer). Isn't there a way of changing how the system automatically mounts such a USB disk? In that case ownership belongs to the user but unfortunately access permissions are not as I would like... Maybe you can suggest this also as a fstab entry in such a way that it will only apply to that particular USB disk, using UID?
– Sadi
Oct 29 '17 at 8:18
True. You originally mentioned this is an USB disk. I edited my answer how Ubuntu behaves with automount and fstab entries are existing.
– V-Mark
Oct 29 '17 at 16:41
True. You originally mentioned this is an USB disk. I edited my answer how Ubuntu behaves with automount and fstab entries are existing.
– V-Mark
Oct 29 '17 at 16:41
Thanks. However, it seems fstab entry (a) requires the presence of that filesystem/partiton/disk during the boot process, therefore, is not useful for removable drives, and (b) results in root ownership of the mounted drive, although permissions are OK, which prevents making any changes there. It seems using the present automount feature, and at the end issuing a command to modify rwx permissions seems to be the only solution available. Is that right?
– Sadi
Oct 30 '17 at 7:54
Thanks. However, it seems fstab entry (a) requires the presence of that filesystem/partiton/disk during the boot process, therefore, is not useful for removable drives, and (b) results in root ownership of the mounted drive, although permissions are OK, which prevents making any changes there. It seems using the present automount feature, and at the end issuing a command to modify rwx permissions seems to be the only solution available. Is that right?
– Sadi
Oct 30 '17 at 7:54
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%2f401102%2fhow-to-copy-files-and-folders-from-a-usb-ntfs-filesystem-to-internal-ext4-withou%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
I don't have a full answer, but my best suggestion at this point would be to create an archive on the NTFS partition, such as a tarball, which can preserve ownerships & permissions internally.
– Jeff Schaller
Oct 28 '17 at 23:28
@JeffSchaller: I’m not sure, but I guess that this problem comes from the fact that Windows conflates read access and execute access — the default permission when you add a user to an ACL is “Read & Executeâ€Â, and you can’t set “Modify†permission without including execute access without using the “Advanced†dialog.  So most files have execute access in the Windows scheme; tar would probably “preserve†that access by setting the
--xbit.– G-Man
Oct 29 '17 at 3:35
@Sadi: People are voting to close this question as “primarily opinion-basedâ€Â, probably because you’re asking for the best way to do something.  You may be able to fix this by changing the question to ask for a good way, and/or specifying objective criteria by which the quality of competing answers is to be evaluated.
– G-Man
Oct 29 '17 at 3:42
@G-Man: Thanks, it seems I should better improve the question a bit...
– Sadi
Oct 29 '17 at 7:38