<y NFS is storing data in "/" instead of "home", what do i have wrong? 'df -h" shows the following:
/dev/mapper/fedora_localhost--live-root 69G 67G 0 100% / tmpfs 1.8G 8.0K 1.8G 1% /tmp /dev/sda2 976M 254M 655M 28% /boot /dev/mapper/fedora_localhost--live-home 3.6T 4.8G 3.4T 1% /home
I need to fix it. I don't know where to look for my mistake, Obviously I want to store files in the 3.4 TB partition not root.
Any help appreciated, Bob
On Sat, 12 Sep 2020 at 11:56, Bob Goodwin bobgoodwin@fastmail.us wrote:
<y NFS is storing data in "/" instead of "home", what do i have wrong? 'df -h" shows the following:
/dev/mapper/fedora_localhost--live-root 69G 67G 0 100% / tmpfs 1.8G 8.0K 1.8G 1% /tmp /dev/sda2 976M 254M 655M 28% /boot /dev/mapper/fedora_localhost--live-home 3.6T 4.8G 3.4T 1% /home
I need to fix it. I don't know where to look for my mistake, Obviously I want to store files in the 3.4 TB partition not root.
I assume the above is for your NFS server. "showmount -e" should show you what directory is exported call it "<some_path>/nfs_share".
Assuming you want to move the exported directory to "/home/nfs_share", there should be an entry for "<some_path>/nfs_share" in "/etc/exports". If you want to avoid changing the client mount commands, you can use a symbolic link:
0. Ask your clients to stop using the share 1. sudo exportfs -u "<some_path>/nfs_share" This disables the share so you can move it
2. sudo mv "<some_path>/nfs_share" /home this should free some space in the root partition
3. sudo ln -s "/home/nfs_share" "<some_path>" this should avoid the need for any NFS configuration changes
4. sudo exportsfs "<some_path>/nfs_share"
This may be an oversimplification, e.g. if you have separate shares for each user. If this isn't what you need, show us the output of "showmount -e" and the contents of "/etc/exports".
On 2020-09-12 11:59, George N. White III wrote:
On Sat, 12 Sep 2020 at 11:56, Bob Goodwin <bobgoodwin@fastmail.us mailto:bobgoodwin@fastmail.us> wrote:
<y NFS is storing data in "/" instead of "home", what do i have wrong? 'df -h" shows the following: /dev/mapper/fedora_localhost--live-root 69G 67G 0 100% / tmpfs 1.8G 8.0K 1.8G 1% /tmp /dev/sda2 976M 254M 655M 28% /boot /dev/mapper/fedora_localhost--live-home 3.6T 4.8G 3.4T 1% /home I need to fix it. I don't know where to look for my mistake, Obviously I want to store files in the 3.4 TB partition not root.I assume the above is for your NFS server. "showmount -e" should show you what directory is exported call it "<some_path>/nfs_share".
. Yes, via ssh: [bobg@WS1 ~]$ ssh -X bobg@192.168.50.32
[bobg@nfs ~]$ showmount -e Export list for nfs: /nfs4exports/home 192.168.50.0/24
Assuming you want to move the exported directory to "/home/nfs_share",
. /I am the onlly client and my fstab is: 192.168.50.32:/nfs4exports/home /media/nfs nfs4 rw,soft,intr,fg,comment=systemd.automout 0 0
/
there should be an entry for "<some_path>/nfs_share" in "/etc/exports
This is what I find in /etc/exports (I odn't remeber how it was created.) [bobg@nfs ~]$ cat /etc/exports /nfs4exports/home 192.168.50.0/24(rw,sync,insecure,no_root_squash,no_subtree_check)
At this point I m lost, I expected the stored files to go to "home" not "/".
Bob -
". If you want to avoid changing the client mount commands, you can use a symbolic link:
0. Ask your clients to stop using the share 1. sudo exportfs -u "<some_path>/nfs_share" This disables the share so you can move it
2. sudo mv "<some_path>/nfs_share" /home this should free some space in the root partition
3. sudo ln -s "/home/nfs_share" "<some_path>" this should avoid the need for any NFS configuration changes
- sudo exportsfs "<some_path>/nfs_share"
This may be an oversimplification, e.g. if you have separate shares for each user. If this isn't what you need, show us the output of "showmount -e" and the contents of "/etc/exports". -- George N. White III
On Sat, 12 Sep 2020 at 15:57, Bob Goodwin bobgoodwin@fastmail.us wrote:
On 2020-09-12 11:59, George N. White III wrote:
On Sat, 12 Sep 2020 at 11:56, Bob Goodwin <bobgoodwin@fastmail.us mailto:bobgoodwin@fastmail.us> wrote:
<y NFS is storing data in "/" instead of "home", what do i have wrong? 'df -h" shows the following: /dev/mapper/fedora_localhost--live-root 69G 67G 0 100% / tmpfs 1.8G 8.0K 1.8G 1% /tmp /dev/sda2 976M 254M 655M 28% /boot /dev/mapper/fedora_localhost--live-home 3.6T 4.8G 3.4T 1% /home I need to fix it. I don't know where to look for my mistake, Obviously I want to store files in the 3.4 TB partition not root.I assume the above is for your NFS server. "showmount -e" should show you what directory is exported call it "<some_path>/nfs_share".
. Yes, via ssh: [bobg@WS1 ~]$ ssh -X bobg@192.168.50.32
[bobg@nfs ~]$ showmount -e Export list for nfs: /nfs4exports/home 192.168.50.0/24
Assuming you want to move the exported directory to "/home/nfs_share",
. /I am the onlly client and my fstab is: 192.168.50.32:/nfs4exports/home /media/nfs nfs4 rw,soft,intr,fg,comment=systemd.automout 0 0
/
there should be an entry for "<some_path>/nfs_share" in "/etc/exports
This is what I find in /etc/exports (I odn't remeber how it was created.) [bobg@nfs ~]$ cat /etc/exports /nfs4exports/home 192.168.50.0/24(rw,sync,insecure,no_root_squash,no_subtree_check)
At this point I m lost, I expected the stored files to go to "home" not "/".
Assuming "/nfs4exports" and " /nfs4exports/home" are regular directories, files stored via the NFS mount will go to the "home" directory under "/nfs4exports", that is, the take space from the root partition. Did you mean to export "/home"? If so, and assuming your user account has the same uid and gid on both systems, it should not be hard to tweak the configuration:
Bob -
". If you want to avoid changing the client mount commands, you can use a symbolic link:
- Ask your clients to stop using the share
Since you are the only client, step 0. becomes (on the client): 0.0) make sure no process is using the NFS mounted filesystem 0.1) "sudo umount /media/nfs"
Back on the server:, step 1 doesn't change
- sudo exportfs -u "<some_path>/nfs_share"
This disables the share so you can move it
Step 2 might need editing:
- sudo mv "<some_path>/nfs_share" /home
this should free some space in the root partition
"<some_path>" turns out to be empty. The above will give you "/home/nfs_share/home". Do you want the shared directory to be "/home/nfs_share" or "/home/bobg/nfs_share" or even "/home/bobg"?
Step 3 depends on what you want in step 2.
- sudo ln -s "/home/nfs_share" "<some_path>"
this should avoid the need for any NFS configuration changes
Since you are the only user affected by the change, you should probably export the directory you choose in step 2 directly so the configuration is unambiguous (symbolic links are an example of the principle that most problems can be solved with another level if indirection). You will need to edit the fstab on the client and "/etc/exports" on the server to replace "/nfs_share" with "/home/<your_choice>".
- sudo exportsfs "<some_path>/nfs_share"
becomes (note the typo exportsfs->exportfs):
4. sudo exportfs "/home/<your_choice>"
This may be an oversimplification, e.g. if you have separate shares for each user. If this isn't what you need, show us the output of "showmount -e" and the contents of "/etc/exports".
On Sat, 2020-09-12 at 14:56 -0400, Bob Goodwin wrote:
On 2020-09-12 11:59, George N. White III wrote:
On Sat, 12 Sep 2020 at 11:56, Bob Goodwin <bobgoodwin@fastmail.us mailto:bobgoodwin@fastmail.us> wrote:
<y NFS is storing data in "/" instead of "home", what do i have wrong? 'df -h" shows the following: /dev/mapper/fedora_localhost--live-root 69G 67G 0100% / tmpfs 1.8G 8.0K 1.8G 1% /tmp /dev/sda2 976M 254M 655M 28% /boot /dev/mapper/fedora_localhost--live-home 3.6T 4.8G 3.4T 1% /home
I need to fix it. I don't know where to look for my mistake, Obviously I want to store files in the 3.4 TB partition not root.I assume the above is for your NFS server. "showmount -e" should show you what directory is exported call it "<some_path>/nfs_share".
. Yes, via ssh: [bobg@WS1 ~]$ ssh -X bobg@192.168.50.32
[bobg@nfs ~]$ showmount -e Export list for nfs: /nfs4exports/home 192.168.50.0/24
Assuming you want to move the exported directory to "/home/nfs_share",
. /I am the onlly client and my fstab is: 192.168.50.32:/nfs4exports/home /media/nfs nfs4 rw,soft,intr,fg,comment=systemd.automout 0 0
/
there should be an entry for "<some_path>/nfs_share" in "/etc/exports
This is what I find in /etc/exports (I odn't remeber how it was created.) [bobg@nfs ~]$ cat /etc/exports /nfs4exports/home 192.168.50.0/24(rw,sync,insecure,no_root_squash,no_subtree_check)
At this point I m lost, I expected the stored files to go to "home" not "/".
/home/nfs4exports would have been in /home Remember you read them left to right.
So /whatever is in / unless otherwise mounted.
So, /home is in / unless it is a mount itself, which yours is.
The first mail of this thread, had:
/dev/mapper/fedora_localhost--live-root 69G 67G 0 100% / tmpfs 1.8G 8.0K 1.8G 1% /tmp /dev/sda2 976M 254M 655M 28% /boot /dev/mapper/fedora_localhost--live-home 3.6T 4.8G 3.4T 1% /home
So, anything that does not start with /tmp, /boot or /home will be in the "root" dir, which we call /.
On Sep 12, 2020, at 14:57, Bob Goodwin bobgoodwin@fastmail.us wrote:
/I am the onlly client and my fstab is: 192.168.50.32:/nfs4exports/home /media/nfs nfs4 rw,soft,intr,fg,comment=systemd.automout 0 0
I see a typo in the “comment=systemd.automout”.
Also, earlier mail makes me think it’s not actually mounted. What does “mount -a” return?
Does /media/nfs exist? Once you get the fstab fixed, test to see if it automounts.
-- Jonathan Billings billings@negate.org
On 2020-09-13 07:21, Jonathan Billings wrote:
On Sep 12, 2020, at 14:57, Bob Goodwin bobgoodwin@fastmail.us wrote:
/I am the onlly client and my fstab is: 192.168.50.32:/nfs4exports/home /media/nfs nfs4 rw,soft,intr,fg,comment=systemd.automout 0 0
I see a typo in the “comment=systemd.automout”.
Also, earlier mail makes me think it’s not actually mounted. What does “mount -a” return?
Does /media/nfs exist? Once you get the fstab fixed, test to see if it automounts.
FWIW, I believe the preferred current option is now
x-systemd.automount
And if desired
x-systemd.idle-timeout= x-systemd.mount-timeout=
See, man systemd.mount
If bob did the exportfs -r prior to mounting /home/whatever that is to be exported then it would have exported the directory on / and not what was later mounted.
He needs to umount the nfs clients, and run exportfs -r on the server and remount on the clients. And make sure that if the directory fails to mount on a reboot then the exportfs -r will need to be rerun.
The showmount -e will not show if it is the dir on / or the dir on the mount.
On Sat, Sep 12, 2020 at 6:31 PM Ed Greshko ed.greshko@greshko.com wrote:
On 2020-09-13 07:21, Jonathan Billings wrote:
On Sep 12, 2020, at 14:57, Bob Goodwin bobgoodwin@fastmail.us wrote:
/I am the onlly client and my fstab is: 192.168.50.32:/nfs4exports/home /media/nfs nfs4 rw,soft,intr,fg,comment=systemd.automout 0 0
I see a typo in the “comment=systemd.automout”.
Also, earlier mail makes me think it’s not actually mounted. What does “mount -a” return?
Does /media/nfs exist? Once you get the fstab fixed, test to see if it automounts.
FWIW, I believe the preferred current option is now
x-systemd.automount
And if desired
x-systemd.idle-timeout= x-systemd.mount-timeout=
See, man systemd.mount
-- The key to getting good answers is to ask good questions. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On 2020-09-12 20:44, Roger Heflin wrote:
If bob did the exportfs -r prior to mounting /home/whatever that is to be exported then it would have exported the directory on / and not what was later mounted.
He needs to umount the nfs clients, and run exportfs -r on the server and remount on the clients. And make sure that if the directory fails to mount on a reboot then the exportfs -r will need to be rerun.
The showmount -e will not show if it is the dir on / or the dir on the mount.
° I tried this several times and ways and finally rebooted the computer and ssh in to the server to do the exportfs -r. However as soon as the computer is booted I found /media /nfs was mounted. I unmounted that, checked to verify the umount was effective and then did the "exportfs -r" command on the nfs server. I also did showmount -e:
[root@nfs bobg]# showmount -e Export list for nfs: /nfs4exports/home 192.168.50.0/24
I also did:
[root@nfs bobg]# ll / ls: unparsable value for LS_COLORS environment variable total 72 lrwxrwxrwx. 1 root root 7 Jul 24 2019 bin -> usr/bin dr-xr-xr-x. 7 root root 4096 Dec 8 2019 boot drwxr-xr-x. 2 root root 4096 Dec 6 2019 data drwxr-xr-x. 20 root root 4200 Sep 13 11:36 dev drwxr-xr-x. 134 root root 12288 Sep 11 22:38 etc drwxr-xr-x. 4 root root 4096 Dec 5 2019 home lrwxrwxrwx. 1 root root 7 Jul 24 2019 lib -> usr/lib lrwxrwxrwx. 1 root root 9 Jul 24 2019 lib64 -> usr/lib64 drwx------. 2 root root 16384 Oct 23 2019 lost+found drwxr-xr-x. 2 root root 4096 Mar 14 2020 media drwxr-xr-x. 5 root root 4096 Mar 7 2020 mnt drwxrwxr-x. 3 bobg bobg 4096 Dec 8 2019 nfs4exports drwxr-xr-x. 2 root root 4096 Jul 24 2019 opt dr-xr-xr-x. 162 root root 0 Sep 11 22:38 proc dr-xr-x---. 8 root root 4096 Sep 13 10:44 root drwxr-xr-x. 43 root root 1320 Sep 13 11:36 run lrwxrwxrwx. 1 root root 8 Jul 24 2019 sbin -> usr/sbin drwxr-xr-x. 2 root root 4096 Jul 24 2019 srv dr-xr-xr-x. 13 root root 0 Sep 11 22:38 sys drwxrwxrwt. 12 root root 260 Sep 13 11:36 tmp drwxr-xr-x. 12 root root 4096 Oct 23 2019 usr drwxr-xr-x. 20 root root 4096 Oct 23 2019 var
My data to be stored is bsing put in /nfs4exports/home/ which is different than /home, but they are all under root. Is "/home" on the 3.4 TB partition or is it still in the 69GB root partition? How do I know? Am I exporting the wrong file?
gparted shows: /dev/sda2 ext4 /boot 1.00 GiB ...etc... /dev/sda3 lvm2 pv fedora_localhost... 3.64 TiB
The more I look at this the more confused I get. Bob
On Sat, Sep 12, 2020 at 6:31 PM Ed Greshko ed.greshko@greshko.com wrote:
On 2020-09-13 07:21, Jonathan Billings wrote:
On Sep 12, 2020, at 14:57, Bob Goodwin bobgoodwin@fastmail.us wrote:
/I am the onlly client and my fstab is: 192.168.50.32:/nfs4exports/home /media/nfs nfs4 rw,soft,intr,fg,comment=systemd.automout 0 0
I see a typo in the “comment=systemd.automout”.
Also, earlier mail makes me think it’s not actually mounted. What does “mount -a” return?
Does /media/nfs exist? Once you get the fstab fixed, test to see if it automounts.
FWIW, I believe the preferred current option is now
x-systemd.automount
And if desired
x-systemd.idle-timeout= x-systemd.mount-timeout=
See, man systemd.mount
-- The key to getting good answers is to ask good questions. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On Sep 13, 2020, at 14:16, Bob Goodwin bobgoodwin@fastmail.us wrote:
The more I look at this the more confused I get.
Maybe you can explain what you expect to see from the output of “ll /“ on the NFS server?
-- Jonathan Billings
Do a "df /nfs4exports/home" an "ls -ld /" a "ls -ld /nfs4exports/home" and a "ls -ld /nfs4exports/" and a "ls -l /nfs4exports".
On the client you can tell which device it is using by what df shows for it, if / it will show the size of / and if correct it will show the sizes of the correct fs.
On Sun, Sep 13, 2020, 1:16 PM Bob Goodwin bobgoodwin@fastmail.us wrote:
On 2020-09-12 20:44, Roger Heflin wrote:
If bob did the exportfs -r prior to mounting /home/whatever that is to be exported then it would have exported the directory on / and not what was later mounted.
He needs to umount the nfs clients, and run exportfs -r on the server and remount on the clients. And make sure that if the directory fails to mount on a reboot then the exportfs -r will need to be rerun.
The showmount -e will not show if it is the dir on / or the dir on the
mount. ° I tried this several times and ways and finally rebooted the computer and ssh in to the server to do the exportfs -r. However as soon as the computer is booted I found /media /nfs was mounted. I unmounted that, checked to verify the umount was effective and then did the "exportfs -r" command on the nfs server. I also did showmount -e:
[root@nfs bobg]# showmount -e Export list for nfs: /nfs4exports/home 192.168.50.0/24
I also did:
[root@nfs bobg]# ll / ls: unparsable value for LS_COLORS environment variable total 72 lrwxrwxrwx. 1 root root 7 Jul 24 2019 bin -> usr/bin dr-xr-xr-x. 7 root root 4096 Dec 8 2019 boot drwxr-xr-x. 2 root root 4096 Dec 6 2019 data drwxr-xr-x. 20 root root 4200 Sep 13 11:36 dev drwxr-xr-x. 134 root root 12288 Sep 11 22:38 etc drwxr-xr-x. 4 root root 4096 Dec 5 2019 home lrwxrwxrwx. 1 root root 7 Jul 24 2019 lib -> usr/lib lrwxrwxrwx. 1 root root 9 Jul 24 2019 lib64 -> usr/lib64 drwx------. 2 root root 16384 Oct 23 2019 lost+found drwxr-xr-x. 2 root root 4096 Mar 14 2020 media drwxr-xr-x. 5 root root 4096 Mar 7 2020 mnt drwxrwxr-x. 3 bobg bobg 4096 Dec 8 2019 nfs4exports drwxr-xr-x. 2 root root 4096 Jul 24 2019 opt dr-xr-xr-x. 162 root root 0 Sep 11 22:38 proc dr-xr-x---. 8 root root 4096 Sep 13 10:44 root drwxr-xr-x. 43 root root 1320 Sep 13 11:36 run lrwxrwxrwx. 1 root root 8 Jul 24 2019 sbin -> usr/sbin drwxr-xr-x. 2 root root 4096 Jul 24 2019 srv dr-xr-xr-x. 13 root root 0 Sep 11 22:38 sys drwxrwxrwt. 12 root root 260 Sep 13 11:36 tmp drwxr-xr-x. 12 root root 4096 Oct 23 2019 usr drwxr-xr-x. 20 root root 4096 Oct 23 2019 var
My data to be stored is bsing put in /nfs4exports/home/ which is
different than /home, but they are all under root. Is "/home" on the 3.4 TB partition or is it still in the 69GB root partition? How do I know? Am I exporting the wrong file? gparted shows: /dev/sda2 ext4 /boot 1.00 GiB ...etc... /dev/sda3 lvm2 pv fedora_localhost... 3.64 TiB
The more I look at this the more confused I get. Bob
On Sat, Sep 12, 2020 at 6:31 PM Ed Greshko ed.greshko@greshko.com
wrote:
On 2020-09-13 07:21, Jonathan Billings wrote:
On Sep 12, 2020, at 14:57, Bob Goodwin bobgoodwin@fastmail.us wrote:
/I am the onlly client and my fstab is: 192.168.50.32:/nfs4exports/home /media/nfs nfs4
rw,soft,intr,fg,comment=systemd.automout 0 0
I see a typo in the “comment=systemd.automout”.
Also, earlier mail makes me think it’s not actually mounted. What
does “mount -a” return?
Does /media/nfs exist? Once you get the fstab fixed, test to see if
it automounts.
FWIW, I believe the preferred current option is now
x-systemd.automount
And if desired
x-systemd.idle-timeout= x-systemd.mount-timeout=
See, man systemd.mount
-- The key to getting good answers is to ask good questions. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
-- Bob Goodwin - Zuni, Virginia, USA FEDORA-32/64bit LINUX XFCE Fastmail POP3 _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On Sun, 13 Sep 2020 at 20:58, Roger Heflin rogerheflin@gmail.com wrote:
Do a "df /nfs4exports/home" an "ls -ld /" a "ls -ld /nfs4exports/home" and a "ls -ld /nfs4exports/" and a "ls -l /nfs4exports".
On the client you can tell which device it is using by what df shows for it, if / it will show the size of / and if correct it will show the sizes of the correct fs.
"df -lhT / /home /nfs4exports /nfs4exports/home" might provide a useful overview. Directories give entries that match their "parent" filesystem. box:
For example, a Fedora 32 system shows:
% df -lhT / /home /usr /usr/local Filesystem Type Size Used Avail Use% Mounted on /dev/mapper/fedora_localhost--live-root ext4 34G 18G 15G 55% / /dev/mapper/fedora_alt-home ext4 151G 68G 76G 48% /home /dev/mapper/fedora_localhost--live-root ext4 34G 18G 15G 55% / /dev/mapper/fedora_alt-local ext4 69G 27G 39G 42% /usr/local
This shows that "/" and "/usr" reside on the same filesystem ("/"), while "/home" and "/usr/local" each reside on a different filesystem.
On 2020-09-13 19:57, Roger Heflin wrote:
Do a "df /nfs4exports/home" an "ls -ld /" a "ls -ld /nfs4exports/home" and a "ls -ld /nfs4exports/" and a "ls -l /nfs4exports".
On the client you can tell which device it is using by what df shows for it, if / it will show the size of / and if correct it will show the sizes of the correct fs.
. I have been using this NFS server for a long time and it has always worked well until root filled and there was no further storage space. I rely on it for the data stored on it, stuff like my calendar, notes, etc.
I collected the requested information:
[bobg@nfs ~]$ df /nfs4exports/home Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/fedora_localhost--live-root 71724152 69849984 0 100% /
[bobg@nfs ~]$ ls -ld / dr-xr-xr-x. 20 root root 4096 Dec 9 2019
[bobg@nfs ~]$ ls -ld /nfs4exports/home drwxrwxr-x. 37 bobg bobg 4096 Sep 10 09:19 /nfs4exports/home
[bobg@nfs ~]$ ls -ld /nfs4exports/ drwxrwxr-x. 3 bobg bobg 4096 Dec 8 2019 /nfs4exports/
[bobg@nfs ~]$ ls -l /nfs4exports total 4 drwxrwxr-x. 37 bobg bobg 4096 Sep 10 09:19 home
[root@WS1 bobg]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 298M 3.6G 8% /dev/shm tmpfs 3.9G 1.7M 3.9G 1% /run /dev/sda5 69G 51G 15G 78% / tmpfs 3.9G 92K 3.9G 1% /tmp /dev/sda1 976M 274M 636M 31% /boot /dev/sda2 839G 29G 767G 4% /home //192.168.50.25/bobg 610G 464G 146G 77% /mnt/smb tmpfs 783M 20K 783M 1% /run/user/1000 192.168.50.32:/nfs4exports/home 69G 67G 0 100% /media/nfs
Obviously the data should be stored in "/home" which is what I expected.
Presentiy /etc/exports is:
[bobg@nfs ~]$ cat /etc/exports /nfs4exports/home 192.168.50.0/24(rw,sync,insecure,no_root_squash,no_subtree_check)
It looks like I am exporting the wrong location/partition ...
On Mon, 14 Sep 2020 at 16:39, Bob Goodwin bobgoodwin@fastmail.us wrote:
On 2020-09-13 19:57, Roger Heflin wrote:
Do a "df /nfs4exports/home" an "ls -ld /" a "ls -ld /nfs4exports/home" and a "ls -ld /nfs4exports/" and a "ls -l /nfs4exports".
On the client you can tell which device it is using by what df shows for it, if / it will show the size of / and if correct it will show the sizes of the correct fs.
. I have been using this NFS server for a long time and it has always worked well until root filled and there was no further storage space. I rely on it for the data stored on it, stuff like my calendar, notes, etc.
I collected the requested information:
[bobg@nfs ~]$ df /nfs4exports/home Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/fedora_localhost--live-root 71724152 69849984 0 100% /
[bobg@nfs ~]$ ls -ld / dr-xr-xr-x. 20 root root 4096 Dec 9 2019
[bobg@nfs ~]$ ls -ld /nfs4exports/home drwxrwxr-x. 37 bobg bobg 4096 Sep 10 09:19 /nfs4exports/home
[bobg@nfs ~]$ ls -ld /nfs4exports/ drwxrwxr-x. 3 bobg bobg 4096 Dec 8 2019 /nfs4exports/
[bobg@nfs ~]$ ls -l /nfs4exports total 4 drwxrwxr-x. 37 bobg bobg 4096 Sep 10 09:19 home
[root@WS1 bobg]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 298M 3.6G 8% /dev/shm tmpfs 3.9G 1.7M 3.9G 1% /run /dev/sda5 69G 51G 15G 78% / tmpfs 3.9G 92K 3.9G 1% /tmp /dev/sda1 976M 274M 636M 31% /boot /dev/sda2 839G 29G 767G 4% /home //192.168.50.25/bobg 610G 464G 146G 77% /mnt/smb tmpfs 783M 20K 783M 1% /run/user/1000 192.168.50.32:/nfs4exports/home 69G 67G 0 100% /media/nfs
Obviously the data should be stored in "/home" which is what I expected.
Presentiy /etc/exports is:
[bobg@nfs ~]$ cat /etc/exports /nfs4exports/home 192.168.50.0/24(rw,sync,insecure,no_root_squash,no_subtree_check)
It looks like I am exporting the wrong location/partition ...
Did you mean to export "/home/nfs4exports"?
On 2020-09-14 18:20, George N. White III wrote:
Presentiy /etc/exports is: [bobg@nfs ~]$ cat /etc/exports /nfs4exports/home 192.168.50.0/24(rw,sync,insecure,no_root_squash,no_subtree_check) <http://192.168.50.0/24(rw,sync,insecure,no_root_squash,no_subtree_check)> It looks like I am exporting the wrong location/partition ...Did you mean to export "/home/nfs4exports"?
-- George N. White III
° If that will store the data in the large "'home" partition that shows only 4% used, yes. But at this point I'm not sure what to do to correct this, can I edit the /etc/exports file in the server directly. I assume I will need to change fstab accordingly too.
On Mon, 14 Sep 2020 at 19:37, Bob Goodwin bobgoodwin@fastmail.us wrote:
On 2020-09-14 18:20, George N. White III wrote:
Presentiy /etc/exports is: [bobg@nfs ~]$ cat /etc/exports /nfs4exports/home 192.168.50.0/24(rw,sync,insecure,no_root_squash,no_subtree_check) <http://192.168.50.0/24(rw,sync,insecure,no_root_squash,no_subtree_check)%3E
Looks like a mail program tried to make a link.
It looks like I am exporting the wrong location/partition ...Did you mean to export "/home/nfs4exports"?
-- George N. White III
° If that will store the data in the large "'home" partition that shows only 4% used, yes. But at this point I'm not sure what to do to correct this, can I edit the /etc/exports file in the server directly. I assume I will need to change fstab accordingly too.
Yes on all counts. We need to work on building your confidence by showing you how to verify that each change you make is working as expected.
On the server, I suggest you copy "/etc/exports" to "/etc/exports.new", edit "/etc/exports.new" to make the change and post the .new file here so others can check for problems. Once you are confident that the changes are good, you can use "showmount -e" to record the current state, then, on the client, unmount the server so you can make the change:
On the client, unmount all nfs filesystems: step 0. sudo umount -a -t nfs Back on the server, you need to stop exporting the old directory,:
step 0: sudo exportfs -u "/nfs_share/home"
then move the data from "/nfs_share/home" to "/home/nfs_share":
step 1: sudo mv /nfs_share/home /home/nfs_share systemctl daemon-reload Check that /nfs_share is empty, that /home/nfs_share has the expected contents, and that the root partition has gained roughly the same space that has been lost on the /hom Check that /nfs_share is empty and that /home/nfs_share has the expected contents.
Update "/etc/exports", and export the new "/home/nfs_share":
step 2. sudo mv /etc/exports /etc/exports.old step 3. sudo mv /etc/exports.new /etc/exports step 4: sudo exportfs -av
Verify that this worked by running "showmount -e"
Back on the client, make a "/etc/fstab.new" with the same process and post for review. The version you posted earlier seems to have a typo, but that may have occurred when posting.
Once you are confident in your fstab, replace the original version with the updated version
step 5: sudo mv /etc/fstab /etc/fstab.old step 6: sudo mv /etc/fstab.new /etc/fstab
Then let systemd know about the changes:
step 7: sudo systemctl daemon-reload step 8: e partition by running "df -lh / /home"
Update "/etc/exports", and export the new "/home/nfs_share":
step 2. sudo mv /etc/exports /etc/exports.old step 3. sudo mv /etc/exports.new /etc/exports step 4: sudo exportfs -av
Verify that this worked by running "showmount -e"
Back on the client, make a "/etc/fstab.new" with the same process and post for review. The version you posted earlier seems to have a typo, but that may have occurred when posting.
Once you are confident in your fstab, replace the original version with the updated version
step 5: sudo mv /etc/fstab /etc/fstab.old step 6: sudo mv /etc/fstab.new /etc/fstab
Then let systemd know about the changes:
step 7: sudo systemctl daemon-reload
Verify that the changes are working: the contents of "/media/nfs" should look the same as they did before the server ran out of space on the root partition.
On 2020-09-15 06:07, George N. White III wrote:
On Mon, 14 Sep 2020 at 19:37, Bob Goodwin <bobgoodwin@fastmail.us mailto:bobgoodwin@fastmail.us> wrote:
On 2020-09-14 18:20, George N. White III wrote: > > > Presentiy /etc/exports is: > > [bobg@nfs ~]$ cat /etc/exports > /nfs4exports/home > 192.168.50.0/24(rw,sync,insecure,no_root_squash,no_subtree_check) <http://192.168.50.0/24(rw,sync,insecure,no_root_squash,no_subtree_check)> > <http://192.168.50.0/24(rw,sync,insecure,no_root_squash,no_subtree_check)>Looks like a mail program tried to make a link.
> > It looks like I am exporting the wrong location/partition ... > > > Did you mean to export "/home/nfs4exports"? > > -- > George N. White III ° If that will store the data in the large "'home" partition that shows only 4% used, yes. But at this point I'm not sure what to do to correct this, can I edit the /etc/exports file in the server directly. I assume I will need to change fstab accordingly too.Yes on all counts. We need to work on building your confidence by showing you how to verify that each change you make is working as expected.
On the server, I suggest you copy "/etc/exports" to "/etc/exports.new", edit "/etc/exports.new" to make the change and post the .new file here so others can check for problems. Once you are confident that the changes are good, you can use "showmount -e" to record the current state, then, on the client, unmount the server so you can make the change:
On the client, unmount all nfs filesystems: step 0. sudo umount -a -t nfs Back on the server, you need to stop exporting the old directory,:
step 0: sudo exportfs -u "/nfs_share/home"
then move the data from "/nfs_share/home" to "/home/nfs_share":
step 1: sudo mv /nfs_share/home /home/nfs_share systemctl daemon-reload Check that /nfs_share is empty, that /home/nfs_share has the expected contents, and that the root partition has gained roughly the same space that has been lost on the /hom Check that /nfs_share is empty and that /home/nfs_share has the expected contents.
Update "/etc/exports", and export the new "/home/nfs_share":
step 2. sudo mv /etc/exports /etc/exports.old step 3. sudo mv /etc/exports.new /etc/exports step 4: sudo exportfs -av
Verify that this worked by running "showmount -e"
Back on the client, make a "/etc/fstab.new" with the same process and post for review. The version you posted earlier seems to have a typo, but that may have occurred when posting.
Once you are confident in your fstab, replace the original version with the updated version
step 5: sudo mv /etc/fstab /etc/fstab.old step 6: sudo mv /etc/fstab.new /etc/fstab
Then let systemd know about the changes:
step 7: sudo systemctl daemon-reload step 8: e partition by running "df -lh / /home"
Update "/etc/exports", and export the new "/home/nfs_share":
step 2. sudo mv /etc/exports /etc/exports.old step 3. sudo mv /etc/exports.new /etc/exports step 4: sudo exportfs -av
Verify that this worked by running "showmount -e"
Back on the client, make a "/etc/fstab.new" with the same process and post for review. The version you posted earlier seems to have a typo, but that may have occurred when posting.
Once you are confident in your fstab, replace the original version with the updated version
step 5: sudo mv /etc/fstab /etc/fstab.old step 6: sudo mv /etc/fstab.new /etc/fstab
Then let systemd know about the changes:
step 7: sudo systemctl daemon-reload
Verify that the changes are working: the contents of "/media/nfs" should look the same as they did before the server ran out of space on the root partition.
-- George N. White III
° I will do as you suggest and report back. I appreciate the time and thought you put into this.
Thank you, Bob
On 2020-09-15 06:58, Bob Goodwin wrote:
I will do as you suggest
° Well, never trusting the "mv" command, I decided to do some experimenting and did:
[root@nfs bobg]# mv /nfs4exports /home/bobg/Public
expecting to move my stored data into "Public" and it did that but the result is not quite what I thought it would be now this is where it is:
/home/bobg/Public/nfs4exports/home
Which I assume is what I would or could export with /etc/ecxports
I think the best ting I might do now is to move thins back to where they were, return the data back to /nfs4exports But it takes a while to run this and I would like to get it right.
Will this restore what I had originally,
mv /home/bobg/Public/nfs4exports/home /nfs4exports
or will it create an even longer file name?
Help, my confidence is shrinking, Bob
mv /home/bobg/Public/nfs4exports / will put it back. mv will "move" the directory and all subdirectories.
Usually to fix something like this (down too many levels) assuming you want that, then go into the directory were the data now is and do mv * ../ and that will relocate it up one directory, that will happen fast as long as . and ../ are on the same mount point, in the same mount point case it will just move the pointers to the data.
On Tue, Sep 15, 2020 at 3:10 PM Bob Goodwin bobgoodwin@fastmail.us wrote:
On 2020-09-15 06:58, Bob Goodwin wrote:
I will do as you suggest
° Well, never trusting the "mv" command, I decided to do some experimenting and did:
[root@nfs bobg]# mv /nfs4exports /home/bobg/Public
expecting to move my stored data into "Public" and it did that but the result is not quite what I thought it would be now this is where it is:
/home/bobg/Public/nfs4exports/home
Which I assume is what I would or could export with /etc/ecxports
I think the best ting I might do now is to move thins back to where they were, return the data back to /nfs4exports But it takes a while to run this and I would like to get it right.
Will this restore what I had originally,
mv /home/bobg/Public/nfs4exports/home /nfs4exports
or will it create an even longer file name?
Help, my confidence is shrinking, Bob
-- Bob Goodwin - Zuni, Virginia, USA FEDORA-32/64bit LINUX XFCE Fastmail POP3 _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On Sep 15, 2020, at 16:10, Bob Goodwin bobgoodwin@fastmail.us wrote:
Will this restore what I had originally,
mv /home/bobg/Public/nfs4exports/home /nfs4exports
or will it create an even longer file name?
No, since you moved the /nfs4exports directory, it is no longer there, so it would move the contents of /home/bobg/Public/nfs4exports/home/ into a directory called /nfs4exports/. So, if there was a /home/bobg/Public/nfs4exports/home/foo, it would now be /nfs4exports/foo.
You could either ‘mkdir /nfs4exports’ first, or move /home/bobg/Public/nfs4exports instead.
-- Jonathan Billings billings@negate.org
On Tue, 15 Sep 2020 at 17:10, Bob Goodwin bobgoodwin@fastmail.us wrote:
On 2020-09-15 06:58, Bob Goodwin wrote:
I will do as you suggest
° Well, never trusting the "mv" command, I decided to do some experimenting and did:
[root@nfs bobg]# mv /nfs4exports /home/bobg/Public
expecting to move my stored data into "Public" and it did that but the result is not quite what I thought it would be now this is where it is:
/home/bobg/Public/nfs4exports/home
More direct would have been "# mv /nfs4exports/home /home/bobg/Public", but the hard work of copying data to the big drive has been done. You should verify that your root partition has gained the same amount of space that you lost on the "/home" partition. As others have already mentioned, it should be a trivial operation to move the contents of "/home/bobg/Public/nfs4exports/home" to one of the parent directories because no files need to copied, just updating some directories.
Which I assume is what I would or could export with /etc/ecxports
I think the best ting I might do now is to move thins back to where they were, return the data back to /nfs4exports But it takes a while to run this and I would like to get it right.
Since your root partition was full before you moved the data to the larger disk, this would be time consuming and could result in major problems if root lost any space to other data (logs) and caused the move back to fail.
It is much safer to leave the data on the large disk and adjust the directory structure. It looks like the choices are to move the contents of "/home/bobg/Public/nfs4exports/home" into either "/home/bobg/Public/nfs4exports" or "/home/bobg/Public". The second option might mix the contents your original "/nfs4exports/home" with whatever was in "~/Public" before you added "nfs4exports". I gather that the only contents of "~/Public/nfs4exports" is the "home" directory, but it might be a good idea to verify that with "ls -l ~/Public/home".
Years ago, when disks were small and our SGI Irix machines each had several external SCSI drives attached, I used to keep a text file in the root of each partition with details of the drive, partition, and notes on the purpose of the partition. Something like that might help you keep track of your filesystem in the future.
Will this restore what I had originally,
mv /home/bobg/Public/nfs4exports/home /nfs4exports
or will it create an even longer file name?
In ideal conditions this (run by "root") would restore your original "/nfs4exports/home", but it is time-consuming and risky due to space constraints in your root partition.
Help, my confidence is shrinking, Bob
You are very close to the desired outcome. Such mistakes are all too easy to make, which is why I like a "buddy system" when doing critical operations. It also helps to maintain a hand-written log where you write down the commands you plan to use with an explanation. Over time you build up a handy reference.
You are welcome to post the command you plan to use here for comments and advice. You should mention the current status and the desired outcome. Extra credit if you show steps to verify that the command did what you wanted it to do.
On 2020-09-16 04:09, Bob Goodwin wrote:
Well, never trusting the "mv" command, I decided to do some experimenting and did:
You know, if you're not comfortable with knowing how a command works or what results it will produce it is best not to work with "live/real" data.
In this case, you could have created a directory structure in the same manner as your real data and used mv on it to see the results.
You could even go so far as to use a VM for testing commands and other things you're concerned may not do as you intend.
On 2020-09-16 01:04, Ed Greshko wrote:
On 2020-09-16 04:09, Bob Goodwin wrote:
Well, never trusting the "mv" command, I decided to do some experimenting and did:
You know, if you're not comfortable with knowing how a command works or what results it will produce it is best not to work with "live/real" data.
In this case, you could have created a directory structure in the same manner as your real data and used mv on it to see the results.
° I am surprised that you are the first one to point out this error in my procedure. I expected to hear that in the first response to my questions.
I have developed some confidence in the people who give me instruction on this list and needed to try the command. I also knew that before asking g any questions I had copied my stored data to another drive on my LAN so if I had a major problem I could still reconstruct things.
But you are right and I usually take care to cover myself when doing things like that. I also looked at the man page and "mv" appears to be a better way to do the job than just coping and erasing later ... I have had some unpleasant surprises with 'rsync' producing copies of directories containing no files? I gave learned to inspect the results, *Bob*
You could even go so far as to use a VM for testing commands and other things you're concerned may not do as you intend.
On Tue, 2020-09-15 at 16:09 -0400, Bob Goodwin wrote:
Well, never trusting the "mv" command, I decided to do some experimenting and did:
When it comes to shifting personal files from spot A to B, especially if I'm starting from a home directory, I tend to use a graphical file manager. Cut from here, paste over there, tends to be quite simple and straightforward. No having to work out difficult wildcards, or workout if I'll accidentally wildcard in something from some other location.
On Wed, 16 Sep 2020 at 09:11, Tim via users users@lists.fedoraproject.org wrote:
On Tue, 2020-09-15 at 16:09 -0400, Bob Goodwin wrote:
Well, never trusting the "mv" command, I decided to do some experimenting and did:
When it comes to shifting personal files from spot A to B, especially if I'm starting from a home directory, I tend to use a graphical file manager. Cut from here, paste over there, tends to be quite simple and straightforward. No having to work out difficult wildcards, or workout if I'll accidentally wildcard in something from some other location.
It is unfortunate that <Ctrl-X> and <Ctrl-C> are next to each other on most keyboards. It would be nice to have a file manager that would display a visual summary of the actions defined by a command-line and let you edit your command line before running it.
When I worked in a place that made Windows the "enterprise standard", and when teaching workshops using student labs where the data files were on a Windows server, users cutting and pasting files, thus removing them from the server was a constant problem. Some Windows sites seem to block or remove read-only permissions in shares, so I never found a way to prevent this. On linux, using sudo, commands are saved to a log so you can review what you did when things didn't go as expected.
On 2020-09-15 19:59, George N. White III wrote:
On Tue, 15 Sep 2020 at 17:10, Bob Goodwin <bobgoodwin@fastmail.us mailto:bobgoodwin@fastmail.us> wrote:
On 2020-09-15 06:58, Bob Goodwin wrote: Well, never trusting the "mv" command, I decided to do some experimenting and did: [root@nfs bobg]# mv /nfs4exports /home/bobg/Public expecting to move my stored data into "Public" and it did that but the result is not quite what I thought it would be now this is where it is: /home/bobg/Public/nfs4exports/homeMore direct would have been "# mv /nfs4exports/home /home/bobg/Public", but the hard work of copying data to the big drive has been done. You should verify that your root partition has gained the same amount of space that you lost on the "/home" partition. As others have already mentioned, it should be a trivial operation to move the contents of "/home/bobg/Public/nfs4exports/home" to one of the parent directories because no files need to copied, just updating some directories.
° /I should have checked df -h before:
/[root@nfs bobg]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 1.8G 0 1.8G 0% /dev tmpfs 1.8G 0 1.8G 0% /dev/shm tmpfs 1.8G 1.3M 1.8G 1% /run /dev/mapper/fedora_localhost--live-root 69G 6.9G 58G 11% / tmpfs 1.8G 8.0K 1.8G 1% /tmp /dev/sda2 976M 254M 655M 28% /boot /dev/mapper/fedora_localhost--live-home 3.6T 65G 3.3T 2% /home tmpfs 360M 8.0K 360M 1% /run/user/987 tmpfs 360M 4.0K 360M 1% /run/user/1000
It shows 65GB removed from "/" and saved to "/home/bobg//Public/nfs4exports/home" which contains the saved files. It's a long file name but I guess I should just export that?
Bob Goodwin - Zuni, Virginia, USA FEDORA-32/64bit LINUX XFCE Fastmail POP3
cd /home/bobg//Public/nfs4exports/home and do a "mv . ../../" and everything in /home/bobg//Public/nfs4exports/home will be moved to /home/bobg/Public (up 2 directories). This will be fast and only move the file headers since both locations are on the same LV/mountpoint.
On Wed, Sep 16, 2020 at 11:07 AM Bob Goodwin bobgoodwin@fastmail.us wrote:
On 2020-09-15 19:59, George N. White III wrote:
On Tue, 15 Sep 2020 at 17:10, Bob Goodwin <bobgoodwin@fastmail.us mailto:bobgoodwin@fastmail.us> wrote:
On 2020-09-15 06:58, Bob Goodwin wrote: Well, never trusting the "mv" command, I decided to do some experimenting and did: [root@nfs bobg]# mv /nfs4exports /home/bobg/Public expecting to move my stored data into "Public" and it did that but the result is not quite what I thought it would be now this is where it is: /home/bobg/Public/nfs4exports/homeMore direct would have been "# mv /nfs4exports/home /home/bobg/Public", but the hard work of copying data to the big drive has been done. You should verify that your root partition has gained the same amount of space that you lost on the "/home" partition. As others have already mentioned, it should be a trivial operation to move the contents of "/home/bobg/Public/nfs4exports/home" to one of the parent directories because no files need to copied, just updating some directories.
° /I should have checked df -h before:
/[root@nfs bobg]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 1.8G 0 1.8G 0% /dev tmpfs 1.8G 0 1.8G 0% /dev/shm tmpfs 1.8G 1.3M 1.8G 1% /run /dev/mapper/fedora_localhost--live-root 69G 6.9G 58G 11% / tmpfs 1.8G 8.0K 1.8G 1% /tmp /dev/sda2 976M 254M 655M 28% /boot /dev/mapper/fedora_localhost--live-home 3.6T 65G 3.3T 2% /home tmpfs 360M 8.0K 360M 1% /run/user/987 tmpfs 360M 4.0K 360M 1% /run/user/1000
It shows 65GB removed from "/" and saved to "/home/bobg//Public/nfs4exports/home" which contains the saved files. It's a long file name but I guess I should just export that?
Bob Goodwin - Zuni, Virginia, USA FEDORA-32/64bit LINUX XFCE Fastmail POP3 _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On 2020-09-16 12:28, Roger Heflin wrote:
cd /home/bobg//Public/nfs4exports/home and do a "mv . ../../" and everything in /home/bobg//Public/nfs4exports/home will be moved to /home/bobg/Public (up 2 directories). This will be fast and only move the file headers since both locations are on the same LV/mountpoint.
° I did: [root@nfs bobg]# mv . ../../ But for whatever reason the the files did not move? I dunno why but I will try that again with something less critical.
Since I am inconvenienced without the NFS server I used the long name to export and in /etc/fstab on the client. I have /media/nfs mounted and have access to the stored files. I still need to reboot the client and make certain I can save to the server.
Thanks for the help,
On Wed, 16 Sep 2020 at 13:29, Roger Heflin rogerheflin@gmail.com wrote:
cd /home/bobg//Public/nfs4exports/home and do a "mv . ../../"
I don't think this will work (maybe depending on the shell program) as the current working directory is in use. Bob had a problem but didn't say what went wrong (the example below uses zsh).
and everything in /home/bobg//Public/nfs4exports/home will be moved to /home/bobg/Public (up 2 directories). This will be fast and only move the file headers since both locations are on the same LV/mountpoint.
Bob: You can convince yourself that the above works by working thru an example.
% cd /tmp % mkdir -p a/b/c $ cd a/b/c $ touch d $ ls -l total 0 -rw-r--r--. 1 u u 0 Sep 16 16:20 d $ mv . ../../ mv: cannot move '.' to '../../.': Device or resource busy % cd - /tmp % cd a % mv b/c . % ls -l total 0 drwxr-xr-x. 2 u u 40 Sep 16 16:38 b drwxr-xr-x. 2 u u 60 Sep 16 16:20 c % ls -l c total 0 -rw-r--r--. 1 u u 0 Sep 16 16:20 d % ls -l b total 0
It ia now safe remove "b"
On Wed, Sep 16, 2020 at 11:07 AM Bob Goodwin bobgoodwin@fastmail.us wrote:
On 2020-09-15 19:59, George N. White III wrote:
On Tue, 15 Sep 2020 at 17:10, Bob Goodwin <bobgoodwin@fastmail.us mailto:bobgoodwin@fastmail.us> wrote:
On 2020-09-15 06:58, Bob Goodwin wrote: Well, never trusting the "mv" command, I decided to do some experimenting and did: [root@nfs bobg]# mv /nfs4exports /home/bobg/Public expecting to move my stored data into "Public" and it did that but the result is not quite what I thought it would be now this is where it is: /home/bobg/Public/nfs4exports/homeMore direct would have been "# mv /nfs4exports/home /home/bobg/Public", but the hard work of copying data to the big drive has been done. You should verify that your root partition has gained the same amount of space that you lost on the "/home" partition. As others have already mentioned, it should be a trivial operation to move the contents of "/home/bobg/Public/nfs4exports/home" to one of the parent directories because no files need to copied, just updating some directories.
° /I should have checked df -h before:
/[root@nfs bobg]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 1.8G 0 1.8G 0% /dev tmpfs 1.8G 0 1.8G 0% /dev/shm tmpfs 1.8G 1.3M 1.8G 1% /run /dev/mapper/fedora_localhost--live-root 69G 6.9G 58G 11% / tmpfs 1.8G 8.0K 1.8G 1% /tmp /dev/sda2 976M 254M 655M 28% /boot /dev/mapper/fedora_localhost--live-home 3.6T 65G 3.3T 2% /home tmpfs 360M 8.0K 360M 1%
/run/user/987
tmpfs 360M 4.0K 360M 1% /run/user/1000
It shows 65GB removed from "/" and saved to "/home/bobg//Public/nfs4exports/home" which contains the saved files. It's a long file name but I guess I should just export that?
Bob Goodwin - Zuni, Virginia, USA FEDORA-32/64bit LINUX XFCE Fastmail POP3 _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
it should have been mv * ../../ I had a brain fart.
Too busy at work trying to figure out why an updated kernel has userspace issues (bash stack smash crash/abort in udevd/late initramfs, a failure to boot), but the old kernel with the exact same userspace is fine.
On Wed, Sep 16, 2020 at 3:00 PM George N. White III gnwiii@gmail.com wrote:
On Wed, 16 Sep 2020 at 13:29, Roger Heflin rogerheflin@gmail.com wrote:
cd /home/bobg//Public/nfs4exports/home and do a "mv . ../../"
I don't think this will work (maybe depending on the shell program) as the current working directory is in use. Bob had a problem but didn't say what went wrong (the example below uses zsh).
and everything in /home/bobg//Public/nfs4exports/home will be moved to /home/bobg/Public (up 2 directories). This will be fast and only move the file headers since both locations are on the same LV/mountpoint.
Bob: You can convince yourself that the above works by working thru an example.
% cd /tmp % mkdir -p a/b/c $ cd a/b/c $ touch d $ ls -l total 0 -rw-r--r--. 1 u u 0 Sep 16 16:20 d $ mv . ../../ mv: cannot move '.' to '../../.': Device or resource busy % cd - /tmp % cd a % mv b/c . % ls -l total 0 drwxr-xr-x. 2 u u 40 Sep 16 16:38 b drwxr-xr-x. 2 u u 60 Sep 16 16:20 c % ls -l c total 0 -rw-r--r--. 1 u u 0 Sep 16 16:20 d % ls -l b total 0
It ia now safe remove "b"
On Wed, Sep 16, 2020 at 11:07 AM Bob Goodwin bobgoodwin@fastmail.us wrote:
On 2020-09-15 19:59, George N. White III wrote:
On Tue, 15 Sep 2020 at 17:10, Bob Goodwin <bobgoodwin@fastmail.us mailto:bobgoodwin@fastmail.us> wrote:
On 2020-09-15 06:58, Bob Goodwin wrote: Well, never trusting the "mv" command, I decided to do some experimenting and did: [root@nfs bobg]# mv /nfs4exports /home/bobg/Public expecting to move my stored data into "Public" and it did that but the result is not quite what I thought it would be now this is where it is: /home/bobg/Public/nfs4exports/homeMore direct would have been "# mv /nfs4exports/home /home/bobg/Public", but the hard work of copying data to the big drive has been done. You should verify that your root partition has gained the same amount of space that you lost on the "/home" partition. As others have already mentioned, it should be a trivial operation to move the contents of "/home/bobg/Public/nfs4exports/home" to one of the parent directories because no files need to copied, just updating some directories.
° /I should have checked df -h before:
/[root@nfs bobg]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 1.8G 0 1.8G 0% /dev tmpfs 1.8G 0 1.8G 0% /dev/shm tmpfs 1.8G 1.3M 1.8G 1% /run /dev/mapper/fedora_localhost--live-root 69G 6.9G 58G 11% / tmpfs 1.8G 8.0K 1.8G 1% /tmp /dev/sda2 976M 254M 655M 28% /boot /dev/mapper/fedora_localhost--live-home 3.6T 65G 3.3T 2% /home tmpfs 360M 8.0K 360M 1% /run/user/987 tmpfs 360M 4.0K 360M 1% /run/user/1000
It shows 65GB removed from "/" and saved to "/home/bobg//Public/nfs4exports/home" which contains the saved files. It's a long file name but I guess I should just export that?
Bob Goodwin - Zuni, Virginia, USA FEDORA-32/64bit LINUX XFCE Fastmail POP3 _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
-- George N. White III
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On 2020-09-16 20:39, Roger Heflin wrote:
it should have been mv * ../../ I had a brain fart.
Too busy at work trying to figure out why an updated kernel has userspace issues (bash stack smash crash/abort in udevd/late initramfs, a failure to boot), but the old kernel with the exact same userspace is fine.
° I wondered about that dot, it asked me if it was ok to write and I told it "Y". No damage done, just left things as they were. And I've learned a new command ...
-
Bob Goodwin -
Doug H. -
Ed Greshko -
George N. White III -
Jonathan Billings -
Roger Heflin -
Tim