the standard path of the mounted USB-device on ipfire is in /mnt
So should i give 777 to /mnt?? Or create /xxx and then give 777 to it?
And what do you mean with user.user? Just the username or something like user.username? I know chown just with user.
As I wrote before I created a /xxx like yours and gave it 777 (leave /mnt as is)
If you want to change user and group with one command, chown user:user somedir will do it (either . or : will work), in effect it is 1) chown user somedir and 2) chgrp user somedir
If the user is bob and belongs to group bob, sudo chown bob:bob somedir
In my client I have a username user who belongs to group user.
ah, ok, thanks, very fine with user:user
so did i, till the point of the mount: access denied by server while mounting serverIP:/xxx/server (not in /mnt)
On server (ipfire) what is in /etc/exports ?
(there is an error here, there is a . before the anonuid, should be comma)
On client, do you have some entry in /etc/fstab to mount /mnt/…
i think also that the problem is here the exports.
i have already ,
maby the IP-range is the problem, i have 192.168.0.0/24
ok, i changed the range and it works… now i check the rw
nope… touch… permission denied
if your network is 192.168.0.0 (and ipfire is 192.168.0.1) yes, the exports line is incorrect since you cannot access 192.168.1.10 (different subnet).
I tested/verified the notes I sent earlier. Post your /etc/exports
The exports line should point to 192.168.2.1 (this is the host that is exporting the nfs)
[root@ipfire ~]# showmount -e localhost
Export list for localhost:
** from my client (Linux mint 19.3)
user@mint:~$ showmount -e ipfire
Export list for ipfire:
(I mount on /media/starter)
sudo mkdir -p /media/starter
sudo chown user.user /media/starter
sudo mount ipfire:/xxx/server /media/starter
user@mint:~$ ls -l /media/starter/
drwxr-xr-x 2 user user 4096 Jul 1 12:40 ./
drwxr-xr-x 5 root root 4096 Jul 1 12:39 …/
-rw-rw-r-- 1 user user 0 Jul 1 12:40 testfile
if I go back to ipfire
[root@ipfire ~]# ls -l /xxx/server/
-rw-rw-r-- 1 samba samba 0 Jul 1 12:40 testfile
The user/group is samba because on ipfire username samba is uid/gid 1000
(which happens to be the same uid/gid on my client pc for username user).
so i have 192.168.2.1/24 now
but still no rw for user
ls -l on server as on the client shows just “root”
the same here:
on the client user is 1000 and on the ipfire samba is 1000
it’s frustrating… but thanks a lot!
definitely frustrating …
(Tried on my pi (username pi), did those 4 commands again:)
sudo mkdir -p /media/server
sudo chown pi.pi /media/server
sudo mount ipfire:/xxx/server /media/server
ls -ldh /media/server umounted is user
ls -ldh /media/server mounted is root
i think because i mount it with sudo. I can write user in fstab, then i can mount it as user, but can not write.
From another client (T5600), the first ls is unmounted …
user@T5600:~$ ls -ldh /media/starter/
drwxr-xr-x 2 user user 4.0K Jul 1 12:39 /media/starter/
user@T5600:~$ sudo mount -vv ipfire:/xxx/server /media/starter/
mount.nfs: timeout set for Thu Jul 2 06:22:18 2020
mount.nfs: trying text-based options ‘vers=4.2,addr=10.0.0.1,clientaddr=10.0.0.26’
user@T5600:~$ ls -ldh /media/starter/
drwxr-xr-x 2 user user 4.0K Jul 1 14:32 /media/starter/
user@T5600:~$ touch /media/starter/anotherfile
user@T5600:~$ sudo umount /media/starter/
- is the same
- mount.nfs: timeout set for Thu Jul 2 21:02:28 2020mount.nfs: trying text-based options ‘vers=4.2,addr=ipfireIP,clientaddr=10.x.x.x’
i suppose here is the point. I use QubesOS. So the client IP is on the one hand in the range of the ipfire, on the other hand it has the 10.x.x.x ip, which is the IP of the VM within QubesOS. The IP it shows me after mount -vv is the IP of the VM and not the client IP of the machine. Can it be the problem?
- is everything root (when mounted)
Do you use virtualbox to start the Qube VM? how is the network interface defined? I think you need to make the network interface a bridge so it will get an ip from your ipfire so that both ipfire and Qube VM are on the same subnet. If you use NAT, the Qube VM will get a 10.0.2.15 which allows it to go outside but not ‘see’ your internal network.
Your network is 192.168.2.* so if you configure the VM to have a bridge network adapter, the VM will get a 192.168.2.xx (where xx is within the range of the ipfire dhcp range).
that will be very complicated, because its not just a virtualbox. The whole System ist in VMs (net-VM for networt interface, firewall-VM for the firewall and app-vm for the personal needs). Do you know QubesOS? It’s a special thing with rather komplex structure. I think i can not manage it, if the problem is the different networks. I have no idea, how can i create a bridge with 192.168.2.x within this structure.
But, what i don’t understand: if i get the connection to the nfs-server, if i can mount it, but can write on it, how can the problem depends on different networks? In that way i could not even get the connection, isn’t it?
So the problem should affect the access privileges…
as i understand the structure, QubesOS forward the 192.168… to the 10.0… so there should be no problem with that. The communication can be realised with the 192.168…
I read about Qubes OS, security focused, https://www.qubes-os.org/intro/ installs on bare metal, runs under Xen and pops VMs (debian/fedora). Tried to install Qubes OS in Virtualbox – failed. Sorry.
no problem, you can not install QubesOS in VB, as i know.
if i chown the /media/server on the client to the user and if it’s mounted it belongs to root, what does affect this?