Solved Permission denied on newly created fs not in fstab.

LibreQuest

LibreQuest

Hey! I have a newbie question.

I have a USB enclosure with a 1TB SATA 2.5" Spinning disk. I have followed this guide,

docs.freebsd.org

Chapter 20. Storage

This chapter covers the use of disks and storage media in FreeBSD. This includes SCSI and IDE disks, CD and DVD media, memory-backed disks, and USB storage devices.
docs.freebsd.org docs.freebsd.org

but I don't want the disk in fstab as it's detachable.

I have mounted the disk with
'mount /dev/da0 /media/da0'

which works as expected.

However, my users which is in groups wheel, operator and video and webcamd etc etc, cannot write to the disk. I can only write to the disk as root.

How should I be mounting this drive to make it writable for my user and not only as root?

Thanks!
 
change ownership to your user name and its primary group ( recursively if you have files and directories on it that you want the user to have control over)
 
Thank you very much. I've got several backup drives to create. I'm moving stuff off of ext4. So this helps tons!
 
Better is to set ACL on the mount point of the mounted file system. That way one doesn't need to apply chmod(1) on the mount point every time the drive is mounted.

Example: The UFS file system is on /dev/da0p1, as root
Code: 
 # tunefs -a enable /dev/da0p1
tunefs(8)
Code: 
     -a enable | disable
             Turn on/off the administrative POSIX.1e ACL enable flag.
Check if enabled:
Code: 
 # tunefs -p /dev/da0p1
tunefs: POSIX.1e: (-a)                               enabled
...

Code: 
 # mount /dev/da0p1 /newdisk

 # setfacl -m g::rwx /newdisk
Sets read, write, and execute permissions for the (wheel) group's POSIX.1e ACL entry on /newdisk. setfacl(1).

Get ACL information on mount point:
Code: 
 # getfacl /newdisk
# file: /newdisk/
# owner: root
# group: wheel
user::rwx
group::rwx
mask::rwx
other::r-x
As seen, group wheel has read/write/execute permissions and a same mask. Every user in the wheel group can create now files and directories with his user name as owner.

Contrary to chmod(1), those permissions are persistent when the drive is unmounted and remounted.
 
T-Daemon said:
Better is to set ACL on the mount point of the mounted file system. That way one doesn't need to apply chmod(1) on the mount point every time the drive is mounted.

Example: The UFS file system is on /dev/da0p1, as root
Code: 
 # tunefs -a enable /dev/da0p1
tunefs(8)
Code: 
     -a enable | disable
             Turn on/off the administrative POSIX.1e ACL enable flag.
Check if enabled:
Code: 
 # tunefs -p /dev/da0p1
tunefs: POSIX.1e: (-a)                               enabled
...

Code: 
 # mount /dev/da0p1 /newdisk

 # setfacl -m g::rwx /newdisk
Sets read, write, and execute permissions for the (wheel) group's POSIX.1e ACL entry on /newdisk. setfacl(1).

Get ACL information on mount point:
Code: 
 # getfacl /newdisk
# file: /newdisk/
# owner: root
# group: wheel
user::rwx
group::rwx
mask::rwx
other::r-x
As seen, group wheel has read/write/execute permissions and a same umask. Every user in the wheel group can create now files and directories with his user name as owner.

Contrary to chmod(1), those permissions are persistent when the drive is unmounted and remounted.
Click to expand...
I do like this option a bit more. Thank you.
 
T-Daemon said:
Better is to set ACL on the mount point of the mounted file system. That way one doesn't need to apply chmod(1) on the mount point every time the drive is mounted.

Example: The UFS file system is on /dev/da0p1, as root
Code: 
 # tunefs -a enable /dev/da0p1
tunefs(8)
Code: 
     -a enable | disable
             Turn on/off the administrative POSIX.1e ACL enable flag.
Check if enabled:
Code: 
 # tunefs -p /dev/da0p1
tunefs: POSIX.1e: (-a)                               enabled
...

Code: 
 # mount /dev/da0p1 /newdisk

 # setfacl -m g::rwx /newdisk
Sets read, write, and execute permissions for the (wheel) group's POSIX.1e ACL entry on /newdisk. setfacl(1).

Get ACL information on mount point:
Code: 
 # getfacl /newdisk
# file: /newdisk/
# owner: root
# group: wheel
user::rwx
group::rwx
mask::rwx
other::r-x
As seen, group wheel has read/write/execute permissions and a same mask. Every user in the wheel group can create now files and directories with his user name as owner.

Contrary to chmod(1), those permissions are persistent when the drive is unmounted and remounted.
Click to expand...
I get
Code: 
tunefs: /dev/da0 is not clean - run fsck.

But after running fsck and finding no issues it repeats the error.

Well, I want to get my backups done so I'll just chown everything for now. Annoying but it will have to due.
 
T-Daemon said:
The UFS partition needs to be unmounted when executing tunefs -a enable /dev/da0p1. Perhaps I should have mention that, but I though it was obvious from my description when the partition is mounted after the ACL flag is enabled.
Click to expand...
Now I no longer feel like a newb but rather a super newb.
 
LibreQuest said:
I have a USB enclosure with a 1TB SATA 2.5" Spinning disk. I have followed this guide,

but I don't want the disk in fstab as it's detachable.
Click to expand...

If you labelled the disk (as da0 could be any other mountable device) then you could have it in fstab with rw,noauto options. But anyway ..

LibreQuest said:
I have mounted the disk with
'mount /dev/da0 /media/da0'
Click to expand...

No partition? What says:
gpart show -p da0

LibreQuest said:
How should I be mounting this drive to make it writable for my user and not only as root?
Click to expand...

The standard method is to set sysctl vfs.usermount=1 once or in /etc/sysctl.conf, then mount a disk on a directory owned by the user.

So perhaps
Code: 
# mkdir /media/LQdir
# chown LQ /media/LQdir
if LQ were your username.

Personally I'd use a directory in my tree like ~smithi/mnt and just mount it there so it's clearly 'mine'.
 
smithi said:
The standard method is to set sysctl vfs.usermount=1 once or in /etc/sysctl.conf, then mount a disk on a directory owned by the user.
Click to expand...
I hope no one minds me jumping in and asking you a question. is that only for FreeBSD FS or would that work with ext4 in fstab too? I could just try it but I figured I ask :rolleyes:

does ext2fs cover ext4 ?

source destination fstype options dump pass
 
Setting posix ACLs is mostly used for fine grained permission control, i personally avoid to complicate things even further it there is no real need for it.

Just use good old chown -R user:group /mnt/flash for example. One ufs partition on HDD/Flash used for data, simple use case, simple solution.
 
Yeah I did the chown and that works but then I read the rest of the handbook entry and there is a section for persistent user permissions for USB mount drives. I just have to follow the rest of the handbook. And then I will look over the options everyone has posted.
 
I've not done this in FreeBSD but in Linux plenty of times when I use a HDD connected to a usb port.

Code: 
I usually lable the partition
chown userName:Group /partitionName -R
even if it is blank sometimes I do the R thing. just cuz it does not hurt it.

when I used ACL it was because I was trying to get the dir or partition to allow read write across the board using the group name. so I can have more than one user name use the same directory on everything in it.
 
Later I will try what is outlined in section

19.4.1. Device Configuration​


In the handbook. It covers user permissions for USB mount.
 
Well, I followed the guide and that didn't work. User still doesn't have permission. Time to try ACL again.
 
chown to my user on the mount dir doesn't work either. Well, I guess I'll just mount and chown everytime and then after I transer my backups I'll fstab those suckers.
 
LibreQuest said:
chown to my user on the mount dir doesn't work either. Well, I guess I'll just mount and chown everytime and then after I transer my backups I'll fstab those suckers.
Click to expand...
okay you mount

mount source destination
sudo mount /dev/drive /mnt (adding whatever fs flag for uts in the proper place)
sudo chown -r userName:group /mnt

then you should be able to mount it in any directory and have rights to it. keeping in mind that /mnt is not a hard core mount point. it just needs to be mounted in a directory
or by hex numbers
sudo find 'path' -type d -exec chmod 755 {} \;

sudo find 'path' -type f -exec chmod 644 {} \;
Click to expand...
keeping in mind that removes all executable permissions on every file.
 
You must log in or register to reply here.
Back
Top