mount permissions for external drives

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)
 
This is not enough ;)
add also:
Code:
own da0s1 root:operator
perm da0s1 0660

replacing s1 with whatever partition you need to mount

shouldn't the wildcard
Code:
own da* root:operator
perm da* 0660

work?

I created $HOME/mnt and I can mount there without sudo like this
Code:
mount /dev/da0s1 /mnt


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?
 
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
Code:
/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]
 
shouldn't the wildcard
Code:
own da* root:operator
perm da* 0660

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 :cool:

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
 
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.
 
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.

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).
 
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
Code:
/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.

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:
Code:
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
 
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

Code:
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

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

Look at this dance
Code:
:~ % 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
 
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?
 
:~ % 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.
 
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
Code:
:~ % 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
 
but the locale IS zh_TW.UTF-8
Code:
:~ % 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

The locales of your account are not related to the problem. It's about loading character set conversion tables into the kernel.
 
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.

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.
 
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.

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

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

I'm not even sure how to proceed, why would they do something like this?
 
@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 :)
 
@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
Code:
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:

Code:
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

Code:
:~ % 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
 
Back
Top