common users should also be able to mount captive-partitions accordingly to the definitions in the /etc/fstab. Currently neither option user(s) nor uid=<name> works as it should. A user is only able to mount a device if 1) device is read/write for user 2) mount point is read/write for user As further error the own user can't even umount it right after: umount: /mnt/captive mount disagrees with the fstab /etc/fstab: /dev/hda1 /mnt/captive captive-ntfs users,uid=1000 0 0 /etc/mtab: lufis /mnt/captive fuse rw,nosuid,nodev,user=<me> 0 0 one user can't read another users mount, neither root can. In my case I'd like to indicate that all / multiple users have access to the mounted device. (i.e. with users / uid= ) User support should be improved, but I don't see how to do this best. Thanks anyway for integrating it into portage and supporting it. I really like your work! Great Thomas Bettler
Created attachment 47369 [details, diff] lufis-allow-uid-and-gid.patch patch for lufis to take uid= and gid= parameters, when the program returns uid=1 or gid=1. It has no check if the value is valid. Please test and comment. A valid fstab entry woudl look like: /dev/hda1 /mnt/captive captive-ntfs defaults,uid=1000,gid=100 0 0
Hm, nope. I tried your patch but it didn't help. I still have to mount the device as the user. Why do you check uid/gid=1 ? Didn't you mean 0 (root,wheel)? But I also tried to check uid/gid against 0 - still negative. In my eyes it would be more consistent to check if uid/gid options are given/valid and depending on that forward these values. Maybe there is an other part (of lufis or maybe fuse or lufs or captive) involved in setting uid/gid permissions. If I can help you somehow let me know, I will provide you all the things you'd like. But I'm no hacker and therefore I'm no way able to fix this bug myself. Anyway Tanks A Lot for your support so far. Your advise was really quick and half way helpful on our way to fix it. Lot of Greetings and a happy new year.
What permissions do you have currently? For me it was always the bin group and user, and this patch tries to attach the uid= user when the uid and/or gid is 1(bin).
I also tried the patch now. At my system it is working very good.
Two questions: 1) I hate to pollute bugzilla with n00b questions, but how do I apply the patch? Do I just stick it in the files folder and add a epatch line to the .ebuild? 2) Looking over the patch (and only the patch mind you, as I have no idea where emerge downloads actual files to in order to look at the source), I see these lines: + // Take uid= and gid= vars when the filesystem returns 1 + if(fattr.f_uid == (uid_t) 1) { + lu_opt_getint(&lu_cfg, "MOUNT", "uid", &option_uid, 0); + fattr.f_uid = (uid_t) option_uid; + } + + if(fattr.f_gid == (gid_t) 1) { + lu_opt_getint(&lu_cfg, "MOUNT", "gid", &option_gid, 0); + fattr.f_gid = (gid_t) option_gid; + } My pure guess as to how lu_opt_getint() works would be that the last param is a default value. If so, souldn't the above lines of code be reduced to: lu_opt_getint(&lu_cfg, "MOUNT", "uid", &fattr.f_uid, 0); lu_opt_getint(&lu_cfg, "MOUNT", "gid", &fattr.f_gid, 0); If my shot in the dark guess is right, this would set the default owner/group to 0 (root), which seems to be a much better default for the owner/group id's than whatever random numbers NT makes up.
On second glance, option_uid and option_gid may still be needed as temp values, but I still suspect we can get rid of the check for 1 as a magic number and always default to root owning the files.
Thats one of the problems with the patch .. the last param is no default param, but instead the type of the string->int conversion. I have no default param at all so it takes some nonsense value from the memory when I dont give uid= and gid=. And sorry, your simplification wont work, because the type is not the same, the type in brackets in the line below is type conversion. Another problem is, that you cant even read the permissions as user (with or without this patch). They are correct .. but this helps little, when the user cant see and use it. How to apply the patch? # emerge lufis [CTRL+Z] after source unpacked. # cd /var/tmp/portage/lufis-0.2/work/lufis-0.2 # patch -p1 < /path/to/patch # fg
Still no success, here. the uid/gid apply, but there is another problem: if I mount /mnt/captive as root: and as root ># ls -l /mnt/captive rw-rw-rw- 1000 100 file1 ... but as user (uid=1000) >$ ls -l /mnt/captive ls: /mnt/captive: Permission denied if I mount /mnt/captive as user everthing works ok and /mnt/captive doen't deny the permission. Any ideas what might be wrong here?
Created attachment 47868 [details, diff] lufis-allow-uid-and-gid.patch Better patch, it now avoids strange values if one only gives one of uid= or gid= or nothing.
Created attachment 47869 [details] /sbin/mount.captive New /sbin/mount.captive allows root to mount with full user r/w access, and also allows the user to umount (if option users is in fstab) What it not aallows, is mounting as user (yet to come ..) My fstab entry now: /dev/hda3 /mnt/captive captive-ntfs defaults,noauto,rw,uid=stefan,users 0 0
please test it and comment, tell me that it works for you or give some feedback ..
Thank you, Stefan! This seems to work for me as far as it should. Using sys-fs/captive-1.1.5-r1 and sys-fs/lufis-0.2 with your second patch and your new /sbin/mount.captive, I CAN * mount my NTFS partition as root (but not as user, as you said) * properly set uid and/or gid by /etc/fstab entry * unmount my NTFS partition as root and as ANY user * read from and write to any directory or file as root * read from and write to directories/files as a normal user according to set permissions I can NOT * chmod directories (an "Operation not permitted" error message is issued) * chmod files (no error message, but no effect either) FWIW, this is my /etc/fstab entry: /dev/hdb1 /mnt/winxp captive-ntfs rw,users,uid=lars,gid=users,noatime,noauto 0 0 and this is the corresponding output line of `mount`: /dev/hdb1 on /mnt/winxp type fuse (rw,nosuid,nodev,allow_other,default_permissions)
Stefan - this worked fine for me! Thanks for all the hard work, i now have full access to NTFS.
It works good here too! :) Tnx for your work.
Is the captive version from http://dev.gentoo.org/~genstef/files/overlay/sys-fs/captive/ ok for you? This will also solve bug 77239 as there is no longer a dependancy on gnome-vfs-httpcaptive. I solved it with an static tarball, if it is not yet on the mirrors, you can get it here: http://dev.gentoo.org/~genstef/files/overlay/captive-install-static-1.1.5.tar.bz2
Emerged your ebuild, which pulled in the following: dev-libs/glib-2.6.2 sys-fs/fuse-2.2 sys-fs/lufis-0.3 sys-fs/captive-1.1.5-r2 Everything works as it used to, PLUS: I can mount as a normal user now, after creating a /etc/fuse.conf with a line 'user_allow_other'. Anything else we should test?
Thank you all for helping on this bug with testing, its now finally in the tree.
