Jump to content

Getting Read/Write Access to Reiserfs Partition


pmpatrick
 Share

Recommended Posts

Just created a reiserfs partition which I want to use for data and backup. This is my fstab entry for the new partition:

 

/dev/hdg9 /mnt/test4 reiserfs notail 1 2

 

I can only write to this partition as root and want to write to it as an ordinary user. I've tried some guesses at editing the fstab entry but no luck. I've looked everywhere but can't find any info on how to edit fstab to give ordinary users read/write access to a reiserfs partition. Odd thing is I can write to /home which is reiserfs which has the same type entry except for 1 1 at the end instead of 1 2. Editing my new partition to 1 1 had no effect so I changed it back. Anybody know the secret?

Link to comment
Share on other sites

Here's mine for my slackware install

/dev/hdb7 /mnt/s reiserfs noatime,nodiratime,notail,defaults 0 0

 

See man mount for what they do. I can't write to it as a user, but from what I've read in man mount the usual will apply here as well, such as umask=0 0 0. The above also stops the boot message; WARNING fs not unmounted properly. :) Reiserfs's should also have read-write in the lilo.conf for /, but this doesn't apply here.

 

You probably should wait and see if someone can actually answer your question.....hehehe....I just wanted to give my 2 cents :wink:

Link to comment
Share on other sites

Alll my reiserfs partitions are the same..

 

/dev/hdc7 / reiserfs notail 1 1

/dev/hdc2 swap swap defaults 0 0

/dev/hdc8 /usr reiserfs notail 1 2

/dev/hdc9 /home reiserfs notail 1 2

/dev/hdc10 /share reiserfs notail 1 2

 

What happens if you unmount the partition and then mount with

 

mount -t auto /dev/hdg9 /mnt/test4

 

?

 

Also, what is hdg9, just a hard drive?

Link to comment
Share on other sites

I know you can't change permissions on mount points to get access; you have to edit fstab. I tried it anyway and it didn't work. Still get access denied. Also tried umask=0 0 0 but got a wrong filesystem error when I tried to mount. I'm pretty sure umask is only for vfat partitions thus the error.

Link to comment
Share on other sites

I don't see the problem. I said above that I can't write to it which is true for "it", but I can write where root says I can just like any other DIR on any OS. Whether root has to do the initial making of a dir I don't know....never tried....no reason to.

 

This is on my data/download reiser partition.

[bvc@localhost bvc]$ mkdir -p /mnt/ftp/home/NEW

mkdir: cannot create directory `/mnt/ftp/home/NEW': Permission denied

[bvc@localhost bvc]$ su

Password:

[root@localhost bvc]# mkdir -p /mnt/ftp/home/NEW

[root@localhost bvc]# chmod 777 -R /mnt/ftp/home/NEW

[root@localhost bvc]# exit

exit

[bvc@localhost bvc]$ mkdir -p /mnt/ftp/home/NEW/bvc

[bvc@localhost bvc]$

Am I missing something here?
Link to comment
Share on other sites

Thanks bvc. Your method works fine. Once you create a directory as root you can change the file permissions to allow user access within the directory. It still seems odd that you can't edit fstab some way to allow users to create directories directly without going throug a previously created directory where permissions are set properly. It's really not a big deal though; when you want to access the partition as an ordinary user you just navigate to the directory where you have permissions and you can write whatever you want. Kind of like having an extra mount point. Thanks again for your help.

Link to comment
Share on other sites

How about permissions on the specific mount folder? Could they be involved? /mnt/test4?

 

Your fstab is correct. You should have read/write. If you don't have data to worry about, you might try removing the partition and re-creating it again. Or perhaps making a new folder and mounting it there (just to see what happens).

Link to comment
Share on other sites

I know devfs can be used to set permissions on devices in /etc/devfsd.conf, and that the full string to the disc (partitions) in /dev ...[example]

/dev/ide/host0/bus0/target0/lun0/part1

can be put in lilo for root=/, and fstab. So, I bet the permissions could be set with these, but it's beyond me. I started to mess with devfsd.conf a bit when I did LFS and couldn't do squat. Didn't try very hard though....I mean...after an LFS install and getting it to boot without 20 errors your brain is pretty much dead :shock: So , you tend to give up real quick on the small stuff. In fact, a crappy ppp connection and trying to figure out devfsd.conf is pretty much what got me so ticked after all the hard work....I formated over that piece of...... :P :lol: Mandrake does a fantastic job with devfs! Go poke through /etc/devfs/conf.d and you'll find things that aren't in slackware and LFS that make life a lot easier, like your modem, mouse, and usbmouse. I think we tend to take a lot for granted really. Do LFS, devfsd, and init scripts by hand and you'll be sending mandrake a thank you check in the mail :wink: Heck....I haven't booted to Slack in 2 weeks...aru I'm not.

Link to comment
Share on other sites

Cannonfodder wrote:

 

Your fstab is correct. You should have read/write. If you don't have data to worry about, you might try removing the partition and re-creating it again. Or perhaps making a new folder and mounting it there (just to see what happens).

 

I tried it and it doesn't work. I created a /mnt/foo and set the permissions rwx all the way across. As soon as I mount /dev/hdg9 through the new mount point, the write permissions drop from user and group(rwxr-xr-x). When I umount, the permissions change back to rwx.

 

I didn't try fooling around with devfs. Actually, I've come to the conclusion that this is a characteristic of native linux file systems. I noticed identical behavior on another ext3 partition where I have redhat 9 installed. Never really had thought about it before since I didn't want ordinary users to have write access from one distro to the other.

My conclusion is that by default/design, only root can write to a native linux partition and root must create a directory(s) and set user permissions to permit ordinary users access. I guess you don't see this probblem with vfat partitions because they have no inherent permission structure by design so there is nothing to set. That is why vfat partitons have ways of coding fstab to allow write access.

My conclusions may be wrong and there may be ways around all this but I'm content to leave things as they are. Thanks again to everyone for their help.

Link to comment
Share on other sites

Don't give up too soon! Here is the answer ;)

 

Since you want a whole partition for all-people-usage why don't you do as if it was the /tmp partition? The /tmp dir (partition or not) is the best example of write for all in your system.

 

I'll show you how to allow writting for all in a partition step by step using as example my /dev/hdb10 partition:

 

Here is what I have, nothing new under the sun (showing just my /tmp and my /dev/hdb10 partitions):

~$ egrep "/tmp|hdb10" /etc/fstab

/dev/hdb9 /tmp reiserfs notail,noexec,nosuid 0 0

/dev/hdb10 /var/local reiserfs notail 0 0

~$

 

Note: you can see which are the real options at /etc/mtab like "rw"; but that doesn't matter at all since we won't touch the fstab file.

 

Now how are the permissions on each mounting point:

~$ ls -ld /var/local /tmp

drwxrwxrwt   20 root     root          744 abr 29 17:00 /tmp/

drwxr-x-w     6 root     root          216 abr 29 17:17 /var/local/

~$

 

Have you seen the difference in permissions?

 

~$ touch /var/local/foobar

touch: creating `/var/local/foobar': Permission denied

~$

 

It is true that if you change the permisions on the mounting point while the filesystem is NOT mounted the change has no effect when you mount it. But if you change its permissions when the fs is MOUNTED, then the changes remain:

 

~# chmod 1777 /var/local

~#

 

Lets try to write something as normal user:

~$ touch /var/local/foobar

~$ ls /var/local/foobar

/var/local/foobar

~$

 

It worked, it was simple, wasn't it?

 

Lets unmount and remount our partition step by step to see if the changes in the permission set have taken effect (and if they remain when mounting again):

 

~# ls -ld /var/local

drwxrwxrwt    6 root     root          216 abr 29 17:22 /var/local/

~# umount /var/local

~# ls -ld /var/local

drwxr-xr-x    2 root     root         4096 feb  6  1996 /var/local/

~# mount /var/local

~# ls -ld /var/local

drwxrwxrwt    6 root     root          216 abr 29 17:22 /var/local/

~#

 

Have you seen how it works?

 

Now you have the whole partition for any user writing access w/o touching your fstab file.

 

It happened that you missed the obvious and you focused your efforts on the wrong approach :D

 

HTH

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...