Default behaviour of mount
The page used to claim that `mount` uses `ntfsmount` from the ntfsprogs package when ntfs-3g is not explicitly stated. This appears to be incorrect (probably outdated), as the ntfs-3g package includes a symlink, /sbin/mount.ntfs, which is used by `mount` on default and points to /bin/ntfs-3g. Correct me if i'm wrong.
- Nope, not gonna correct you, TaylanUB. Just tested an you're right. By default (in Arch) it uses ntfs-3g now. So this is good news. I think the install cd might still but for regular installs, we're good. Thanks for the updated information. Fixing.
- Edit: Oop or not fixing. Thanks for doing TaylanUB.
- --Gen2ly 18:58, 9 April 2010 (EDT)
umask: umask is a built-in shell command which automatically sets file permissions on newly created files. For Arch the default umask for root and user is 0022. With 0022 new folders have the directory permissions of 755 and new files have permissions of 644. You can read more about umask permissions here.
unmask with 0022 is only for root, that means as user you can't create or delete something. The right option for user is 0002.
- I'm not sure what you mean by the "right option". There is certainly no harm in setting a more restrictive value of 0022 for users. And this is the default for Arch . Closing.
- Silverhammermba (talk) 18:38, 30 January 2017 (UTC)
/etc/fstab and the type parameter
Using my home server and its ntfs partition I discovered an issue in the wiki, that you can confirm or not. If in /etc/fstab I identify the ntfs partition with the 'ntfs-3g' parameter, like in the wiki, the partition is inaccessible and unmounted. The fstab isn't completely processed. But if I identify that with the 'ntfs' parameter it works perfectly as expected.
- I can confirm that it is possible to mount an NTFS partition via the
ntfs-3gtype in fstab. Closing. Silverhammermba (talk) 18:22, 30 January 2017 (UTC)
not sure if this warrants a separate article but shouldn't dofstools be mentioned somewhere - maybe here?
I'm an Arch noob and I only found out how to format a partition as fat32 from the live-usb article.
- It is covered in File Systems. If you type "Arch fat32" you can get your answer in the first result. This is also true for most of Arch related topic. Just add Arch into the keyword. -- Fengchao (talk) 12:14, 10 June 2013 (UTC)
Allowing user to mount: sudo as an option
This may be (or I suspect it is) a dangerous option, but as a person who just can't be bothered with computer security (as long as nothing happens, that is), I have happily existed this way since starting to use Arch.
Wouldn't it make sense to discuss the sudo option? This is what I do; I do not precisely remember why I did this (because I probably tried to follow the standard advice first), but it might have been the only apparent option with my setting: I have a dual-boot configuration with Windoze 8 (which I use less and less, but I sometimes have to).
What makes ntfs-3g crucial in this situation is that I have always wanted my home directory to be fully accessible from both operating systems, not just some shove-files-back-and-forth solution. (And actually, I do consider this quite a natural requirement if you want to get work done.)
Thus, I created a separate partition for my home directory and had Windows format it as NTFS. The full NTFS file attributes/permissions were not interesting to me, but for the user to basically have ownership of the files in his/her home partition while under Linux, (s)he must mount it him-/herself. (Ownership is not permanently stored with the files, however; I think it might be possible to achieve this if you delve into the NTFS file attributes etc. business.)
Since you need your home partition to be mounted before you even log in, however, I think the only possible way to achieve that was like this:
# /etc/sudoers username hostname = NOPASSWD: /usr/bin/mount username hostname = NOPASSWD: /usr/bin/umount
# /etc/fstab /dev/sda12 /home/username ntfs-3g auto,uid=1000,gid=100,exec,umask=0022 1 1 # ^^^^
Not sure if I am leaving out something important here, but this setting works fine. (I think the read/write attributes are permanent, while the executable bit is not. Thus, I have to have mount indiscriminately set ALL files on the partition as executable because I have a number of scripts stored on my home directory which I want to be executable.) As I have already mentioned, I am not aware of the security risks of this configuration (and I don't know if I really want to know them ;-)), but it seems to me that given the proper security warnings, this is an option worth mentioning.
- The part you're missing is that now any user can mount file systems with suid files on them, and thus can get root access trivially. At the least, add
-o nosuid,nodevto the sudoers config. -- Alad (talk) 10:58, 1 September 2016 (UTC)
- I'm pretty sure that having
/homeon an NTFS volume will break a lot of stuff due to permissions not being correctly persisted. Off the top of my head, I know that SSH really won't like it because it is particular about private key permissions. You should mount your NTFS volume elsewhere and link it up with your home directory using symlinks or bind mounts. Then you should be able to mount it as specified in the article. Silverhammermba (talk) 15:30, 1 September 2016 (UTC)
- I'm pretty sure that having
- Closing due to inactivity. Also I fail to see any reason for sudo being involved here. I have an NTFS partition that I mount using fstab where my user has rw ownership of all files, even though the user does not have permission to mount/umount the partition:
UUID=blah /home/max/data ntfs-3g uid=max,gid=users,dmask=022,fmask=133 0 0
- Silverhammermba (talk) 18:48, 30 January 2017 (UTC)