# mount permissions for external drives



## bcomputerguy (Jan 11, 2018)

I'm not sure why but I cannot mount external drives w/o using sudo...


```
sysctl vfs.usermount
vfs.usermount: 1
```

to /etc/sysctl.conf add

```
vfs.usermount=1
```


/etc/devfs.conf

```
own     da0    root:operator
perm    da0    0660
```

/etc/devfs.rules

```
[localrules=5]
add path 'da*' mode 0660 group operator
```

to /etc/rc.conf add

```
devfs_system_ruleset="localrules"
```


```
groups
username wheel operator
```


----------



## bookwormep (Jan 12, 2018)

For the /etc/devfs.rules

```
add path 'da[0-9]\*' mode 666
```

I have used this on my system.


----------



## Snurg (Jan 12, 2018)

Did you chgrp the mountpoints to 'operator'?

Btw, I have serious doubts that it's a good idea to allow 'others' full r/w access to /dev/daX.


----------



## bcomputerguy (Jan 12, 2018)

Snurg said:


> Did you chgrp the mountpoints to 'operator'?
> 
> Btw, I have serious doubts that it's a good idea to allow 'others' full r/w access to /dev/daX.



The /dev/da* looks like this with ls -l


```
ls -l /dev/da*
crw-r-----  1 root  operator  0x70 Jan 12 13:02 /dev/da0
crw-r-----  1 root  operator  0x76 Jan 12 13:02 /dev/da0s1
```

Does that look okay?


----------



## bcomputerguy (Jan 12, 2018)

bookwormep said:


> For the /etc/devfs.rules
> 
> ```
> add path 'da[0-9]\*' mode 666
> ...



I updated my devfs.rules; still a no go

```
[localrules=5]
add path 'da*' mode 0660 group operator
add path 'da[0-9]\*' mode 0660 group operator
```


----------



## Snurg (Jan 12, 2018)

The group members cannot write to the device. Maybe this is not necessary if you only intend to mount things other than ZFS with -o r[o] option. But trying to mount r/w will fail without write rights.
`chmod g+w /dev/da0*`


----------



## bcomputerguy (Jan 12, 2018)

Snurg said:


> The group members cannot write to the device. Maybe this is not necessary if you only intend to mount things other than ZFS with -o r[o] option. But trying to mount r/w will fail without write rights.
> `chmod g+w /dev/da0*`



I did that and I am still getting operation not permitted when run as non root user.


```
ls -l /dev/da*
crw-rw----  1 root  operator  0x6b Jan 12 13:33 /dev/da0
```

after running

```
chmod g+w /dev/da0*
```


----------



## Snurg (Jan 12, 2018)

And how does look/mnt (or whatever you use as mount point)?
Is it also owned by group operator?


----------



## bcomputerguy (Jan 12, 2018)

This is

```
ls -l /
-rw-r--r--   1 root  wheel         0 Jan 11 09:18 $
drwxr-xr-x   2 root  wheel        46 Dec 14 21:15 bin
drwxr-xr-x   9 root  wheel        57 Jan 12 13:17 boot
drwxr-xr-x   3 root  wheel         3 Nov 26 13:27 compat
-r--r--r--   1 root  wheel      6192 Nov 21 22:57 COPYRIGHT
dr-xr-xr-x   8 root  wheel       512 Jan 12 21:33 dev
-rw-------   1 root  wheel      4096 Jan 12 13:34 entropy
drwxr-xr-x  26 root  wheel       116 Jan 12 04:11 etc
lrwxr-xr-x   1 root  wheel         8 Nov 26 18:58 home -> usr/home
drwxr-xr-x   4 root  wheel        57 Dec 14 21:15 lib
drwxr-xr-x   3 root  wheel         7 Dec 14 21:16 libexec
drwxr-xr-x   2 root  wheel         2 Nov 21 22:55 media
drwxr-xr-x   2 root  wheel         2 Jan 12 03:40 mnt
-rw-------   1 root  wheel  16306176 Jan  8 15:29 mtpfs.core
drwxr-xr-x   2 root  wheel         2 Nov 21 22:55 net
dr-xr-xr-x   2 root  wheel         2 Nov 21 22:55 proc
drwxr-xr-x   2 root  wheel       149 Dec 14 21:15 rescue
drwxr-xr-x  11 root  wheel        18 Jan 12 13:07 root
drwxr-xr-x   2 root  wheel       135 Dec 14 21:16 sbin
lrwxr-xr-x   1 root  wheel        11 Dec 14 21:14 sys -> usr/src/sys
drwxrwxrwt  11 root  wheel        37 Jan 12 19:42 tmp
drwxr-xr-x  16 root  wheel        16 Nov 26 19:04 usr
drwxr-xr-x  25 root  wheel        25 Jan 12 21:34 var
drwxr-xr-x   3 root  wheel         3 Dec 12 19:20 zroot
```


```
% groups
username wheel operator
```


----------



## Snurg (Jan 12, 2018)

If you want to user mount on /mnt, it would probably be helpful to have it also group operator and group-writable.


----------



## bcomputerguy (Jan 12, 2018)

Snurg said:


> If you want to user mount on /mnt, it would probably be helpful to have it also group operator and group-writable.



How would I go about doing that?


----------



## Snurg (Jan 12, 2018)

`chgrp operator /mnt
chmod g+w /mnt`


----------



## bcomputerguy (Jan 12, 2018)

Snurg said:


> `chgrp operator /mnt
> chmod g+w /mnt`



I am not sure what's going on but none of that is working. Maybe my permissions are all messed up.


```
:~ % ls -l /dev/da0*
crw-rw----  1 root  operator  0x73 Jan 12 20:33 /dev/da0
crw-rw----  1 root  operator  0x74 Jan 12 20:33 /dev/da0s1
:~ % ls -l / | grep mnt
drwxrwxr-x   2 root  operator         2 Jan 12 03:40 mnt
```



```
:~ % mount_msdosfs /dev/da0s1 /mnt/
mount_msdosfs: /dev/da0s1: Operation not permitted
```


```
:~% sudo mount_msdosfs /dev/da0s1 /mnt/
sudo mount_msdosfs /dev/da0s1 /mnt/
```

sudo can mount the drive, regular user cannot.


----------



## Snurg (Jan 12, 2018)

Theoretically it should work. For some reason it does not always.
You can try `chown <yourusername> /mnt`.
If that does not work, I have to apologize for my incompetence, as I must have missed something. Then we have to hope for some guru like SirDice or others to help.

Edit: I haven't tried yet to `mount /something /mnt/`. I always do use /mnt in this case, because /mnt denotes the directory, /mnt/ denotes its contents.


----------



## bookwormep (Jan 12, 2018)

I would offer only a small additional note, just trying to help here, /etc/devfs.rules

```
[localrules=10]
```
and that "mode 666", not "mode 0660"


----------



## Snurg (Jan 12, 2018)

I just looked at `man devfs.rules`.
If you make a localrule, you need to activate it explicitly.
But if you just add the
`add path 'da*' mode 660 group operator`
line, _without_ a localrule, it should be active permanently.
I didn't find how to reload devfs rules, and I do not want to reboot just now, so I'll check it out later myself.

Edit: `service devfs restart`. But there is still something to do. As bookwormep said, mode 666 works. But I do not believe that this is a good way to solve this. There must be another way, too.
Edit 2: Yes. Add a devfs line with the group the user to be allowed mounting belongs to. Then it works with 660.


----------



## bcomputerguy (Jan 12, 2018)

Snurg said:


> I just looked at `man devfs.rules`.
> If you make a localrule, you need to activate it explicitly.
> But if you just add the
> `add path 'da*' mode 660 group operator`
> ...



I have been rebooting during this process and it is still not working.
I just reread the devfs.rules man page as well.

Based on that I updated my /etc/devfs.rules to look like this:


```
[localrules=10]
add path 'da*s*' mode 0660 group operator
```

I'd just like to add for clarity, this is the mount command that I am trying to run

```
~ % mount_msdosfs -L en_US.UTF-8 -D UTF-8 /dev/da0s1 /mnt/
```


```
~ % mount_msdosfs /dev/da0s1 /mnt/
```

Neither of those above commands work as a regular user.
They work as sudo though....



bookwormep said:


> I would offer only a small additional note, just trying to help here, /etc/devfs.rules
> 
> ```
> [localrules=10]
> ...



I tried that but that didn't work either.


----------



## Snurg (Jan 12, 2018)

See the edits in my last post.
It works with

```
add path 'da*' mode 660 group operator
add path 'da*' mode 660 group <myusergroup>
```

where <myusergroup> is the group the user belongs to (usually same name as username)
Edit: this is _without_ localrules!


----------



## bcomputerguy (Jan 12, 2018)

Snurg said:


> See the edits in my last post.
> It works with
> 
> ```
> ...



something is definitely wrong with my setup.

Even with the above edits, I still get operation not permitted.

There's something seriously broken with my permissions.


----------



## Snurg (Jan 12, 2018)

There was still one difference: I had 
`chown <myusername>:<myusername> /mnt`
because this saved me from write permissions problems. Maybe this is what is still missing to make it work for you...


----------



## bcomputerguy (Jan 12, 2018)

Snurg said:


> There was still one difference: I had
> `chown <myusername>:<myusername> /mnt`
> because this saved me from write permissions problems. Maybe this is what is still missing to make it work for you...



That works...
Why do I have to set the user and permission like that to get /mnt to work?


----------



## mrclksr (Jan 12, 2018)

bcomputerguy said:


> I'd just like to add for clarity, this is the mount command that I am trying to run
> 
> ```
> ~ % mount_msdosfs -L en_US.UTF-8 -D UTF-8 /dev/da0s1 /mnt/
> ```



If the module msdosfs_iconv is not loaded, `mount_msdosfs` tries to load it, but this not possible if you execute it as regular user.

As Snurg mentioned, make sure the mount point is owned by the user.

From mount_msdosfs(8):


> This command is normally executed by mount(8) at boot
> time, but can be used by *any user* to mount an MS-DOS file system on any
> directory that *they own* (provided, of course, that they have appropriate
> access to the device that contains the file system).



I'd recommend to create a mnt directory under ${HOME} or create a msdosfs (or any other name you prefer) directory under /media, followed by `chown username /media/msdosfs`


----------



## bcomputerguy (Jan 12, 2018)

mrclksr said:


> If the module msdosfs_iconv is not loaded, `mount_msdosfs` tries to load it, but this not possible if you execute it as regular user.
> 
> As Snurg mentioned, make sure the mount point is owned by the user.
> 
> ...



A lot of those _msdos or windows file mounting commands require fuse or something similar.
Is it possible to have all these loaded through /etc/rc.conf or /boot/loader.conf 

Would that avoid these types of issue?


----------



## Sensucht94 (Jan 12, 2018)

bookwormep said:


> For the /etc/devfs.rules
> 
> ```
> add path 'da[0-9]\*' mode 666
> ...



Please notice that 'da[0-9]\*' applies the permission scheme only to nodes from 0 to 9, while 'da*' applies it to any. However, since I think nobody here's going to to plug more than 9 mass storage peripherals into his/her own computer at a time, this wouldn't make any difference, unless you use a USB port extender, and insert more than 9 usb/SD devices all at once, in which case, the the tenth would be read-only.


bookwormep said:


> I would offer only a small additional note, just trying to help here, /etc/devfs.rules
> 
> ```
> [localrules=10]
> ```


the number specified in /etc/devfs.rules corresponds to the number ruleset you want to create, technically, it does not change anything, aside from the fact that each ruleset need its own unique number. More than 1 ruleset can be specified at a time inside /etc/devfs.rules (this comes in handy for example when needing to create a ruleset for a chroot env, a jail, a different user, a different mountpoint). Ruleset number can be specified with `-s` option and mount_point with `-m`. For instance:

`devfs -m ~/jail/dev rule -s 5 applyset` applies ruleset 5, to devices listed under jail's  /dev directory.
To list a ruleset:
`devfs rule -s 5 show`

Now, if no ruleset is specified in /etc/rc.conf  the rules applied at boot are the ones from /etc/defaults/devfs.rules. This file already takes ruleset numbers from 1 to 4. If a number between 1 and 4 is appended to any of the user's local ruleset in /etc/devfs.rules, the latter takes precedence and overrides the corresponding ruleset in /etc/defaults. If local rulesets are numbered higher than 4, and loaded in /etc/rc.conf, then local user's rules are merged with defaults.



> and that "mode 666", not "mode 0660"


This actually gives read/write permission to `"others"`: as long as the user belongs to the group which devices' ownership is granted to in /etc/devfs.conf, then this is shoudn't be needed



Snurg said:


> `chgrp operator /mnt
> chmod g+w /mnt`



I'm almost sure this would be reset to default at the next boot no sooner devd is started, hence could be used only for the current session



> If you make a localrule, you need to activate it explicitly


Snurg, OP stated he tried to do so the moment he opened the thread 



> I didn't find how to reload devfs rules, and I do not want to reboot just now, so I'll check it out later myself.



I mentioned it above, but for a proper knowledge see devfs(8)
To apply my standard ruleset at boot (which is `[localrules=5]`) I have, in /etc/rc.conf:

```
devfs_load_ruleset="YES"
devfs_rulesets="/etc/devfs.rules"
devfs_system_ruleset="localrules"
```
To learn more, see rc.conf(5)...since it's a long man page, just type `man rc.conf | less -Sip "rulesets"`



> If you want to user mount on /mnt, it would probably be helpful to have it also group operator and group-writable.


This is definitely true bcomputerguy, user needs ownership + read/write permissions for the mount point,
The suggestion Snurg gave to you:


> chgrp operator /mnt
> chmod g+w /mnt



is undoubtedly good. However, since you're experiencing problems, why don't you try to mount devices somewhere inside your $HOME first?
For example I'm used to mount things inside ~/Devices.

Finally please beware that, just basing on my experience, if file system to be mounted is slightly corrupted, you won't be able to mount it as standard user. A `fsck`, to dispel any doubt, wouldn't harm.
Speaking of the `ls -l /dev/da*` output you pasted above, for me it's appears ruleset is not being applied for some reason.

Side note: you'll need fuse only for EXT4, exFAT, NTFS and XFS


----------



## Sensucht94 (Jan 12, 2018)

bcomputerguy said:


> /etc/devfs.conf
> 
> ```
> own da0 root:operator
> ...



Try adding also:

```
own da0s1 root:operator
perm da0s1 0660
```

replacing s1 with whatever partition you need to mount


----------



## Snurg (Jan 12, 2018)

Sensucht94 said:


> I'm almost sure this would be reset to default at the next boot no sooner devd is started, hence could be used only for the current session


I forgot to mention that this must be done _before_ mounting on that. This way it will be permanent.
Having a custom rule for jails is a good thing anyway, as it is not always necessary to allow jails having access to zfs commands. (See rule #4 in /etc/defaults/devfs.rules)


----------



## mrclksr (Jan 12, 2018)

bcomputerguy said:


> Is it possible to have all these loaded through /etc/rc.conf or /boot/loader.conf


Yes. Just add [FONT=Courier New]msdosfs_iconv_load="YES"[/FONT] to /boot/loader.conf or set [FONT=Courier New]kld_list="msdosfs_iconv"[/FONT] to /etc/rc.conf


----------



## bcomputerguy (Jan 12, 2018)

Sensucht94 said:


> This is not enough
> add also:
> 
> ```
> ...



shouldn't the wildcard

```
own da* root:operator
perm da* 0660
```

work?

I created $HOME/mnt and I can mount there without sudo like this

```
mount /dev/da0s1 /mnt
```




mrclksr said:


> Yes. Just add [FONT=Courier New]msdosfs_iconv_load="YES"[/FONT] to /boot/loader.conf or set [FONT=Courier New]kld_list="msdosfs_iconv"[/FONT] to /etc/rc.conf


Does this mean if I want to setup a machine to mount msdosfs_iconv based files they'll need to make these edits as well?


----------



## mrclksr (Jan 12, 2018)

If you're interested in a fully automated solution, check out this Thread 63534


----------



## mrclksr (Jan 12, 2018)

bcomputerguy said:


> Does this mean if I want to setup a machine to mount msdosfs_iconv based files they'll need to make these edits as well?



Yes.


----------



## bcomputerguy (Jan 12, 2018)

mrclksr said:


> If you're interested in a fully automated solution, check out this Thread 63534



You know, I was just working on a custom mounting solution because none of the others worked for me.

automount just mounts devices and they can't be read or just some jankiness, like adding stuff like this

```
/media          -media          -nosuid,-m=770,-L=en_US.UTF-8
```
to auto_master, but it still doesn't work properly.

sysutils/automount just never gets locale correct so my documents are useless.
Even after configuring the automount.conf file.

＠mrclksr
I'll take a look at yours and see if that solves the problem.

The script that I wrote is based off devfs rules to then call a script; it currently only handles msdos files.

It's just one [currently UGLY] #!/bin/sh script;

If you'd like to see it, I can share it.

*[FONT=Consolas][/FONT]*


----------



## Sensucht94 (Jan 12, 2018)

bcomputerguy said:


> shouldn't the wildcard
> 
> ```
> own da* root:operator
> ...



Sure it would, if you want to apply the ownership-permission scheme to any partition/slice of any mass storage device you insert, which is what I do too 



> I created $HOME/mnt and I can mount there without sudo like this


Glad you worked it out! I wonder now why you were not able to mount it on /mnt...maybe I missed something, but didn't you state through the various posts, that you had changed /mnt ownership to match your user, and granted user r/w permissions for it?

Anyway, now it may be time to configure automounting , either with autofs(5) with sysutils/automount or with mrclksr's  systutils/dsbmd+sysutils/dsbmc, as he mentioned above


----------



## bcomputerguy (Jan 12, 2018)

so, there are no mounters that will allow a non root user to load a drive with locale settings?

I can mount the drive now to $HOME/mnt but I can't read or copy them because their filenames are all garbled.


----------



## mrclksr (Jan 12, 2018)

bcomputerguy said:


> so, there are no mounters that will allow a non root user to load a drive with locale settings?



You can of course, as regular user, specify which locale conversion to use with the [FONT=Courier New]-L[/FONT] flag as you did. But this requires the msdosfs_iconv module to be loaded. You can load it at run time as root (`kldload msdosfs_iconv`) or at boot time as mentioned before.



bcomputerguy said:


> I can mount the drive now to $HOME/mnt but I can't read or copy them because their filenames are all garbled.


Is msdosfs_iconv.ko loaded? (`kldstat | grep msdosfs_iconv`).


----------



## Sensucht94 (Jan 12, 2018)

bcomputerguy said:


> You know, I was just working on a custom mounting solution because none of the others worked for me.
> 
> automount just mounts devices and they can't be read or just some jankiness, like adding stuff like this
> 
> ...



And here we go again with the nightmare of  AUTOFS' `-media` special map. I've never managed to make it work neither in BSD nor in Linux, to the point I came to miss the old days of Berkley's amd(8), which is by the way still available (sysutils/am-utils), albeit deprecrated (I guess NetBSD is the only one to keep using it, as all other Linux distros, BSDs and OpenIndiana are with AUTOFS). There are some who claim it works, for me it doesn't, no matter what (guess I'm missing something). In Linux, as long as your DE or File Manager takes care of it, everything's fine, but in FreeBSD you need to completely rely on autofs(5), and it's configuration file: /etc/auto_master.
The awesome man page available auto_master(5) helps one to understand  how mount points and maps (direct , indirect,special) work(useful also for Linux usage). I read it carefully countless times, and created tons of maps with custom properties and mountpoints, always respecting the given syntax: the map is created and mounted as expected, but devices somehow keep to be mounted under /media.

So far there's only a gross workaround I managed to find: comment all lines inside /etc/auto_master, so that no mountpoint, nor map is specified or loaded (=as if file were blank). Devices will be then mounted inside /media, but without the
`-media` map loaded first on the folder, which for me turns in devices being mounted read-only. Now change ownership  and permissions of `/media`  folder:

```
chown -R username:wheel /media
chmod 0774 /media
```

Job done, devices are automounted read/write, works also with FUSE

As for problems with files being displayed, I think you should load msdos_iconv.ko


----------



## bcomputerguy (Jan 12, 2018)

mrclksr said:


> You can of course, as regular user, specify which locale conversion to use with the [FONT=Courier New]-L[/FONT] flag as you did. But this requires the msdosfs_iconv module to be loaded. You can load it at run time as root (`kldload msdosfs_iconv`) or at boot time as mentioned before.
> 
> 
> Is msdosfs_iconv.ko loaded? (`kldstat | grep msdosfs_iconv`).



I feel like I broke something because that module is loaded, I added it to kld_list in /etc/rc.conf


```
Id Refs Address            Size     Name
10    1 0xffffffff85e89000 806      msdosfs_iconv.ko
```

I can mount_msdos to $HOME/mnt w/o sudo
as soon as I add the locale, it fails


```
:~ % mount_msdosfs -L zh_TW.UTF-8 /dev/da0s1 mnt/
mount_msdosfs: msdosfs_iconv: Operation not permitted
```

Look at this dance

```
:~ % mount_msdosfs /dev/da0s1 mnt/
:~ % ls mnt/
ls: FU-360??-01.PDF: Invalid argument
050-E01-01.PDF
:~ % umount mnt/
:~ % mount_msdosfs -L zh_TW.UTF-8 -D UTF-8 /dev/da0s1 mnt/
mount_msdosfs: msdosfs_iconv: Operation not permitted
```


----------



## mrclksr (Jan 12, 2018)

Set [FONT=Courier New]msdosfs_locale = zh_TW.UTF-8[/FONT] in /usr/local/etc/dsbmd.conf, and (re)start dsbmd with `service dsbmd onerestart`. Then mount the device using `dsbmc-cli -m /dev/da0s1` as regular user. Can you now access the files?


----------



## mrclksr (Jan 13, 2018)

bcomputerguy said:


> :~ % mount_msdosfs -L zh_TW.UTF-8 -D UTF-8 /dev/da0s1 mnt/ mount_msdosfs: msdosfs_iconv: Operation not permitted


I can reproduce that behavior, and I remember having this problem when implementing the locale support in `dsbmd`, which was solved by setting the locale as root before switching the EUID and EGID. The problem is that a desired character conversation table must be present in the kernel. If that's not the case,  it must be defined, which is a problem without sufficient permission. If root executes `mount_msdosfs -L zh_TW.UTF-8 /dev/da0s1 mnt`, `mount_msdosfs` can set the conversation table for converting DOS/Win95 filenames to UTF-8. Now a regular user can execute `mount_msdosfs -L <insert locale>.UTF-8 /dev/da0s1 mnt`.


----------



## bcomputerguy (Jan 13, 2018)

mrclksr said:


> I can reproduce that behavior, and I remember having this problem when implementing the locale support in `dsbmd`, which was solved by setting the locale as root before switching the EUID and EGID. The problem is that a desired character conversation table must be present in the kernel. If that's not the case,  it must be defined, which is a problem without sufficient permission. If root executes `mount_msdosfs -L zh_TW.UTF-8 /dev/da0s1 mnt`, `mount_msdosfs` can set the conversation table for converting DOS/Win95 filenames to UTF-8. Now a regular user can execute `mount_msdosfs -L <insert locale>.UTF-8 /dev/da0s1 mnt`.



but the locale IS zh_TW.UTF-8

```
:~ % locale
LANG=zh_TW.UTF-8
LC_CTYPE="zh_TW.UTF-8"
LC_COLLATE="zh_TW.UTF-8"
LC_TIME="zh_TW.UTF-8"
LC_NUMERIC="zh_TW.UTF-8"
LC_MONETARY="zh_TW.UTF-8"
LC_MESSAGES="zh_TW.UTF-8"
LC_ALL=zh_TW.UTF-8
```

It's set at login through .login_conf


----------



## mrclksr (Jan 13, 2018)

bcomputerguy said:


> but the locale IS zh_TW.UTF-8
> 
> ```
> :~ % locale
> ...



The locales of your account are not related to the problem. It's about loading character set conversion tables into the kernel.


----------



## mrclksr (Jan 13, 2018)

You can either use this solution or you could use sysutils/kiconvtool (https://wiki.freebsd.org/DmitryMarakasov/kiconvtool).


----------



## bcomputerguy (Jan 13, 2018)

mrclksr said:


> You can either use this solution or you could use sysutils/kiconvtool (https://wiki.freebsd.org/DmitryMarakasov/kiconvtool).



Quick question,
even if the user's env already has encoding en_US.UTF-8;
just providing the -L option to mount_msdosfs causes things to fail?

This doesn't make sense to me.
Why not at lease use the user's current locale?


----------



## mrclksr (Jan 13, 2018)

bcomputerguy said:


> even if the user's env already has encoding en_US.UTF-8;
> just providing the -L option to mount_msdosfs causes things to fail?


Yes.



bcomputerguy said:


> Why not at lease use the user's current locale?


A user's locale is basically just a set of environment variables, which are used by applications to decide how to present certain kinds of data to the user. `mount_msdosfs` could of course use the user's locale settings, but it has to tell the kernel, and so the situation is not different from using the [FONT=Courier New]-L[/FONT] flag. An unprivileged process (`mount_msdosfs` executed as regular user) is not allowed to instruct the kernel to load character conversation tables into kernel memory.

From https://wiki.freebsd.org/DmitryMarakasov/kiconvtool


> This is caused by the fact that character set conversion tables need to be loaded into kernel, but, apart from mounting, that's not allowed to plain users, because charset tables are large enough to initiate a denial of service by filling kernel memory with many tables.


----------



## bcomputerguy (Jan 13, 2018)

mrclksr said:


> Yes.
> 
> 
> A user's locale is basically just a set of environment variables, which are used by applications to decide how to present certain kinds of data to the user. `mount_msdosfs` could of course use the user's locale settings, but it has to tell the kernel, and so the situation is not different from using the [FONT=Courier New]-L[/FONT] flag. An unprivileged process (`mount_msdosfs` executed as regular user) is not allowed to instruct the kernel to load character conversation tables into kernel memory.
> ...



This seems really strange, some sort of catch-22...

I'm not even sure how to proceed, why would they do something like this?


----------



## Snurg (Jan 13, 2018)

@bsdcomputerguy If I understand correctly, the kiconvtool preloads the character conversion tables you specify.
If you then use these with -L, they do not need to be loaded (causing operation not permitted error), but can be used directly.
So you only need to say kiconvtool which character sets it shall load, and then you can use these as unprivileged user.

In short, this kiconvtool seems to be a really cool thing


----------



## bcomputerguy (Jan 14, 2018)

Snurg said:


> @bsdcomputerguy If I understand correctly, the kiconvtool preloads the character conversion tables you specify.
> If you then use these with -L, they do not need to be loaded (causing operation not permitted error), but can be used directly.
> So you only need to say kiconvtool which character sets it shall load, and then you can use these as unprivileged user.
> 
> In short, this kiconvtool seems to be a really cool thing



This I hope is user error but not even that's working for me.

kldstat

```
Id Refs Address            Size     Name
10    1 0xffffffff85e89000 806      msdosfs_iconv.ko
11    1 0xffffffff85e8a000 4633     libiconv.ko
```

I don't know the encoding for zh_TW as that seems to fail but following the documentation and using his examples:


```
Specify all required local charsets with -l flag and all
          required foreign charsets with -f flag. For example:

            kiconvtool -l KOI8-R -f CP866 UTF-16BE
```

I still get the same errors


```
:~ % kiconvtool -l KOI8-R -f CP866 UTF-16BE
kiconvtool: kiconv_add_xlat16_cspairs(KOI8-R:CP866): Operation not permitted
kiconvtool: kiconv_add_xlat16_cspairs(KOI8-R:UTF-16BE): Operation not permitted
```


----------

