Re: [PLUG] Ubuntu MATE 18.04 frustrations

[Dick Steffens]

While I haven't been using MythTV for a couple of years, I still follow 
their mailing list. Others have commented on issues with Ubuntu 18.04, 
though not MATE specifically. Here's one of the comments:


Ubuntu do not enable upgrades from 16.04 LTS to 18.04 LTS until
18.04.1 is released.  That allows them to work out any bugs in the
upgrade process and make sure 18.04 is stable.  So even if you are
doing a new install instead of upgrading, I think it would be a good
idea to wait for 18.04.1.


I'm not doing an upgrade, but it's instructive to see that there might 
be issues with the initial release. I think I'll put off working on this 
until after the point release comes out.


--
Regards,

Dick Steffens

___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Ubuntu MATE 18.04 frustrations

[Dick Steffens]

On 05/17/2018 10:47 PM, Tomas K wrote:

I'd be rather careful with modifying users on existing system - unless
you know exactly what you are doing. It can have pretty nasty side
effects appearing/re-appearing and entertaining you for long time to
come, at the 'best' possible times.


I had a feeling it wasn't quite as simple as I'd hoped. At this point, 
it's almost easier to start over. It wouldn't be the first time I've 
installed a new OS more than once. I might even remove the 482 GB drive 
entirely (I have a USB box for SATA drives) and skip the part about 
figuring out why it takes so long to transfer files from it to the other 
drive on the same machine. I also have a noisy fan bearing, so I need to 
pull the box out from under the desk, anyway. It's one of those 
intermittent issues, so it will take some fussing to figure out which 
fan is the culprit.


But, I have learned two major things from the exercise, how to use 
rsync, and how someone decided to make what used to be a simple task 
more complicated, i.e. letting Caja talk to other machines.


Thanks for all the hand holding along the way. It may be a couple of 
weeks before I have time to tackle this again.


--
Regards,

Dick Steffens

___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Ubuntu MATE 18.04 frustrations

[Tomas K]

I'd be rather careful with modifying users on existing system - unless
you know exactly what you are doing. It can have pretty nasty side
effects appearing/re-appearing and entertaining you for long time to
come, at the 'best' possible times.

Local users and file ownership in Linux is established by UID.
User name is just a name for UID on a particular system.
  * so if you change user name (not UID), nothing has really changed
beside the user name displayed on given host.
  * if you see file owned by dick - there must be a user for that UID
with name dick on your system, otherwise you would see familiar nobody.
  * so based on UID on a particular systems you could be rsteff on
both, but with different UIDs. So when you copy those files -
preserving UID, you lose ownership and the new owner becomes someone
else or Mr/Mrs nobody.

When you use rsync to copy stuff between systems - the ownership gets
translated.
When you use NFS mounts (v3 or newer) between systems, the ownership
gets translated too as long as there are matching user names on all
connected hosts.

So as you can guess - it is good idea to follow bunch of rules when
managing a herd of standalone linux hosts without centralized user
management:
1. Synchronize UIDs and user names across all hosts.
   You do not have to have all users on all hosts, but their UIDs and
user name pairs should match.
  It is good practice to replicate users though an disable them when
needed, so that their old files still have an owner.
2. Synchronize GIDs and group names across all hosts - for precisely
the same reasons as 1.

Forward looking thoughts:
-
Following these two rules will make your shepherd's (no pun intended)
life much easier. Although following these rules across your herd can
get pretty tedious over time - leading some shepherds to use central
user, group, host,  management such as LDAP or FreeIPA (mentioned
here a few weeks ago). That combined with networked storage makes
computers orders of magnitude more useful.

Having central user management (AKA information services) and
associated DNS, NFS, DHCP, etc. used to be pretty expensive proposition
from IT, electricity and man power cost. This is no longer the case
with the advent of RaspberryPi type of computers which cost almost
nothing in IT and electricity cost and are pretty easy to connect to
your network and forget about them. RPi type computers also enable
pretty cheap/easy redundancy and backup - which is a must with
centralized services - because when they go down everything tends to
get stuck. Pulling another RPi from your drawer with identical setup to
the old one, and saving the day, makes you feel pretty darm good about
yourself.

Tomas

On Thu, 2018-05-17 at 16:26 -0700, Dick Steffens wrote:
> On 05/17/2018 04:21 PM, Rich Shepard wrote:
> > On Thu, 17 May 2018, Dick Steffens wrote:
> > 
> > > That part I know. What I've never looked into is how to change
> > > the 
> > > name of user dick to user rsteff, not from a file ownership 
> > > perspective, but from who is logged in. I'm sure I could create 
> > > another user named rsteff, but I don't think that's what I mean
> > > to 
> > > do, either.
> > 
> > Dick,
> > 
> >   Perhaps this will help:
> >  > 34075>
> > 
> >   For details, 'man usermod(8)':
> > 
> > NAME
> >    usermod - modify a user account
> > 
> > SYNOPSIS
> >    usermod [options] LOGIN
> > 
> > DESCRIPTION
> >    The usermod command modifies the system account files to 
> > reflect the
> >    changes that are specified on the command line.
> >   ...
> > 
> > -l, --login NEW_LOGIN
> >    The name of the user will be changed from LOGIN to
> > NEW_LOGIN.
> >    Nothing else is changed. In particular, the user's home 
> > directory
> >    or mail spool should probably be renamed manually to 
> > reflect the
> >    new login name.
> > 
> > HTH,
> > 
> 
> Thanks. That's probably what I need.
> 
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Ubuntu MATE 18.04 frustrations

[Rich Shepard]

On Thu, 17 May 2018, Dick Steffens wrote:


Thanks. That's probably what I need.


Dick,

  I learned only recently of usermod and groupmod. One of the applications I
use (don't recall which one) changed the default user and group IDs when I
installed the upgrade and I had to change them back to the ones that exist
here.

Best regards,

Rich

___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Ubuntu MATE 18.04 frustrations

[Dick Steffens]

On 05/17/2018 04:21 PM, Rich Shepard wrote:

On Thu, 17 May 2018, Dick Steffens wrote:

That part I know. What I've never looked into is how to change the 
name of user dick to user rsteff, not from a file ownership 
perspective, but from who is logged in. I'm sure I could create 
another user named rsteff, but I don't think that's what I mean to 
do, either.


Dick,

  Perhaps this will help:


  For details, 'man usermod(8)':

NAME
   usermod - modify a user account

SYNOPSIS
   usermod [options] LOGIN

DESCRIPTION
   The usermod command modifies the system account files to 
reflect the

   changes that are specified on the command line.
  ...

-l, --login NEW_LOGIN
   The name of the user will be changed from LOGIN to NEW_LOGIN.
   Nothing else is changed. In particular, the user's home 
directory
   or mail spool should probably be renamed manually to 
reflect the

   new login name.

HTH,



Thanks. That's probably what I need.

--
Regards,

Dick Steffens

___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Ubuntu MATE 18.04 frustrations

[Rich Shepard]

On Thu, 17 May 2018, Dick Steffens wrote:

That part I know. What I've never looked into is how to change the name of 
user dick to user rsteff, not from a file ownership perspective, but from who 
is logged in. I'm sure I could create another user named rsteff, but I don't 
think that's what I mean to do, either.


Dick,

  Perhaps this will help:


  For details, 'man usermod(8)':

NAME
   usermod - modify a user account

SYNOPSIS
   usermod [options] LOGIN

DESCRIPTION
   The usermod command modifies the system account files to reflect the
   changes that are specified on the command line.
  ...

-l, --login NEW_LOGIN
   The name of the user will be changed from LOGIN to NEW_LOGIN.
   Nothing else is changed. In particular, the user's home directory
   or mail spool should probably be renamed manually to reflect the
   new login name.

HTH,

Rich

___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Ubuntu MATE 18.04 frustrations

[Dick Steffens]

On 05/17/2018 03:55 PM, Rich Shepard wrote:

On Thu, 17 May 2018, Dick Steffens wrote:

I'll probably go through the learning curve of changing the user name 
one

of these days.)


Dick

  'chown -R rsteff *' (or whatever files you want to change. Leave off 
the

quotes, of course.


That part I know. What I've never looked into is how to change the name 
of user dick to user rsteff, not from a file ownership perspective, but 
from who is logged in. I'm sure I could create another user named 
rsteff, but I don't think that's what I mean to do, either.




I'm familiar with chown -R because usually, when I copy files from 
another machine, they end up being owned by nobody:nobody, although I 
haven't ever used $USER.


This was between other, older Ubuntu implementations, not between this 
18.04 installation and the 16.04 one.



  Perhaps this is a ubuntu family 'feature?'. When the drive with the
dick-owned files is mounted run the above command via sudo. It may be 
that
the permissions are too restricted for rsteff to change ownership of 
files

owned by dick on that drive.


At this point, rsteff does not exist on ENU-1, so I'm not trying to 
change the ownership of anything there.


--
Regards,

Dick Steffens


___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Ubuntu MATE 18.04 frustrations

[Rich Shepard]

On Thu, 17 May 2018, Rich Shepard wrote:


Perhaps this is a ubuntu family 'feature?'.


  Apologies for the sarcasim.


When the drive with the dick-owned files is mounted run the above command
via sudo. It may be that the permissions are too restricted for rsteff to
change ownership of files owned by dick on that drive.


  Elaboration: if the dick-owned files have permission 644 then only user
dick can change their ownership because neither group members nor others
have write permissions on those files. Root does, though.

Rich
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Ubuntu MATE 18.04 frustrations

[Rich Shepard]

On Thu, 17 May 2018, Dick Steffens wrote:


I'll probably go through the learning curve of changing the user name one
of these days.)


Dick

  'chown -R rsteff *' (or whatever files you want to change. Leave off the
quotes, of course.

I'm familiar with chown -R because usually, when I copy files from another 
machine, they end up being owned by nobody:nobody, although I haven't ever 
used $USER.


  Perhaps this is a ubuntu family 'feature?'. When the drive with the
dick-owned files is mounted run the above command via sudo. It may be that
the permissions are too restricted for rsteff to change ownership of files
owned by dick on that drive.

Rich
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Ubuntu MATE 18.04 frustrations

[Dick Steffens]

On 05/17/2018 11:31 AM, Tomas K wrote:

I suspect that your local disk access issue may be permissions if you
changed uid between the installations.

That should be easy to check for:
ls -l /media/dick/a857c2f6-6e1a-4afe-9d6e-8109105a740
Do you own any files there?


That drive used to be the only drive on a machine back in the days of 
12.04, so it has all the 12.04 system files on it. I did drill down to 
/home/rsteff and found that all of the files there are owned by user 
dick. (I usually use rsteff as my user name, but didn't this time. I'll 
probably go through the learning curve of changing the user name one of 
these days.)



If you do not own the files an directories and you think that you
should, you can do it this way:
sudo chown -R $USER /media/dick/a857c2f6-6e1a-4afe-9d6e-
8109105a740/someDirOrFile


I'm familiar with chown -R because usually, when I copy files from 
another machine, they end up being owned by nobody:nobody, although I 
haven't ever used $USER. I'll try that the next time. I'll describe 
another solution to the copying problem in a minute, but oddly, files I 
copied that way from the 16.04 machine to the 18.04 machine came through 
owned by dick, rather than nobody.



Then, you can try if your access to the disk is any better.


Today, when I turned the 18.04 machine on, I didn't mount the 482 GB 
drive right away, but followed a procedure I got from the Ubuntu MATE 
community. Here's the process:


On the 18.04 machine:
1. Open *caja*
2. Click *File - Connect to Server...*
3. In the *Connect to Server* dialog box select *Windows share* as *Type*
4. Enter the *Server* name
    I was successful using either ENU-2 (the name I gave the machine) 
or its IP address.


5. Enter *Share* (name)
    For this I used Public, which is a folder I shared on that machine.

6. Remove the */* from the *Folder* field
    I skipped that the first time, but then realized I needed to remove 
it, otherwise this process would try to look at the root folder.

    Indeed, I got an error message when I tried that.

7. Enter the *Domain Name* (usually or if not really configured *WORKGROUP*)
    Here, I have the domain set to HOUSE, so I used that.

8. Enter *User Name* and
    rsteff

9. Enter *Password* valid for the share
    rsteff's password on ENU-2

10. Check *Remember this password*
11. Check *Add bookmark*
12. Enter a *Bookmark name*
13. Click *Connect

*After doing all those things, I got a Caja window looking at the Public 
folder for user rsteff on ENU-2, and successfully copied files from it. 
As I mentioned above, they came through assigned to user dick on ENU-1.

**
After doing that I mounted the 482 GB drive. It took a long time to show 
up in Caja, and I heard it crunching. I don't know for sure what it was 
doing, but eventually it finished, and I could look at files there.



Hope it helps,Tomas


Yes, thanks.

--
Regards,

Dick Steffens


___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Ubuntu MATE 18.04 frustrations

[Tomas K]

I suspect that your local disk access issue may be permissions if you
changed uid between the installations.

That should be easy to check for:
ls -l /media/dick/a857c2f6-6e1a-4afe-9d6e-8109105a740
Do you own any files there?

If you do not own the files an directories and you think that you
should, you can do it this way:
sudo chown -R $USER /media/dick/a857c2f6-6e1a-4afe-9d6e-
8109105a740/someDirOrFile

Then, you can try if your access to the disk is any better. 

Hope it helps,Tomas

On Wed, 2018-05-16 at 09:00 -0700, Dick Steffens wrote:
> On 05/16/2018 01:48 AM, Tomas K wrote:
> > Great to hear that the file copy problem is out of the way.If you
> > keep
> > that rsync command in your toolbox, it works incrementally. The
> > next
> > time you run it, it will only copy new files on the other way. If
> > you
> > change the source and destination, it will copy new files to the
> > other
> > machine.
> > 
> > To see your local drive, you will need to mount it.
> > You said:
> > >    Can you see it mouted by: mount?
> > 
> > Yes. /dev/sda2 on /
> > 
> > That does not seem to be right - as that is your new installation
> > root
> > directory.
> 
> Sorry. Typo, or misread. The 482 GB drive is:
> 
> /dev/sdb1 on /media/dick/a857c2f6-6e1a-4afe-9d6e-8109105a740 type
> ext4 
> (rw,nosuid, nodev,relative,date=ordered,uhelper=udisks2)
> 
> > Can you post output of following commands:
> > sudo fdisk -l
> 
> Disk /dev/loop0: 86.7 MiB, 90923008 bytes, 177584 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> 
> 
> Disk /dev/loop1: 71.7 MiB, 75120640 bytes, 146720 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> 
> 
> Disk /dev/loop2: 86.6 MiB, 90759168 bytes, 177264 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> 
> 
> Disk /dev/loop3: 7.9 MiB, 8294400 bytes, 16200 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> 
> 
> Disk /dev/loop4: 7.5 MiB, 7884800 bytes, 15400 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> 
> 
> Disk /dev/loop5: 86.6 MiB, 90828800 bytes, 177400 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> 
> 
> Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 4096 bytes
> I/O size (minimum/optimal): 4096 bytes / 4096 bytes
> Disklabel type: gpt
> Disk identifier: 476788A2-28E0-4D9E-BF80-AEE9A112B59B
> 
> Device   Start    End    Sectors  Size Type
> /dev/sda1 2048    1050623    1048576  512M EFI System
> /dev/sda2  1050624 1953523711 1952473088  931G Linux filesystem
> 
> 
> Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x000698ae
> 
> Device Boot Start   End   Sectors   Size Id Type
> /dev/sdb1  * 2048 960258047 960256000 457.9G 83 Linux
> /dev/sdb2   960260094 976771071  16510978   7.9G  5 Extended
> /dev/sdb5   960260096 976771071  16510976   7.9G 82 Linux swap /
> Solaris
> 
> > cat /etc/fstab
> 
> # /etc/fstab: static file system information.
> #
> # Use 'blkid' to print the universally unique identifier for a
> # device; this may be used with UUID= as a more robust way to name
> devices
> # that works even if disks are added and removed. See fstab(5).
> #
> #           
> # / was on /dev/sda2 during installation
> UUID=e1ff5590-d1ce-44be-9f10-7ce2bdd432c1 /   ext4 
> errors=remount-ro 0   1
> # /boot/efi was on /dev/sda1 during installation
> UUID=E8BB-3F15  /boot/efi   vfat    umask=0077  0   1
> /swapfile none    swap 
> sw  0   0
> 
> 
> I don't have the 482 GB drive in fstab. It was disconnected during
> the 
> install, since I put a bunch of stuff there I want to copy to the
> main 
> drive now that the install is finished. I just mount it as needed by 
> clicking on it in Caja's Devices list.
> 
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Ubuntu MATE 18.04 frustrations

[Dick Steffens]

On 05/16/2018 01:48 AM, Tomas K wrote:

Great to hear that the file copy problem is out of the way.If you keep
that rsync command in your toolbox, it works incrementally. The next
time you run it, it will only copy new files on the other way. If you
change the source and destination, it will copy new files to the other
machine.

To see your local drive, you will need to mount it.
You said:

   Can you see it mouted by: mount?

Yes. /dev/sda2 on /

That does not seem to be right - as that is your new installation root
directory.


Sorry. Typo, or misread. The 482 GB drive is:

/dev/sdb1 on /media/dick/a857c2f6-6e1a-4afe-9d6e-8109105a740 type ext4 
(rw,nosuid, nodev,relative,date=ordered,uhelper=udisks2)



Can you post output of following commands:
sudo fdisk -l

Disk /dev/loop0: 86.7 MiB, 90923008 bytes, 177584 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop1: 71.7 MiB, 75120640 bytes, 146720 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop2: 86.6 MiB, 90759168 bytes, 177264 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop3: 7.9 MiB, 8294400 bytes, 16200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop4: 7.5 MiB, 7884800 bytes, 15400 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop5: 86.6 MiB, 90828800 bytes, 177400 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 476788A2-28E0-4D9E-BF80-AEE9A112B59B

Device   Start    End    Sectors  Size Type
/dev/sda1 2048    1050623    1048576  512M EFI System
/dev/sda2  1050624 1953523711 1952473088  931G Linux filesystem


Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000698ae

Device Boot Start   End   Sectors   Size Id Type
/dev/sdb1  * 2048 960258047 960256000 457.9G 83 Linux
/dev/sdb2   960260094 976771071  16510978   7.9G  5 Extended
/dev/sdb5   960260096 976771071  16510976   7.9G 82 Linux swap / Solaris


cat /etc/fstab


# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#           
# / was on /dev/sda2 during installation
UUID=e1ff5590-d1ce-44be-9f10-7ce2bdd432c1 /   ext4 
errors=remount-ro 0   1

# /boot/efi was on /dev/sda1 during installation
UUID=E8BB-3F15  /boot/efi   vfat    umask=0077  0   1
/swapfile none    swap 
sw  0   0



I don't have the 482 GB drive in fstab. It was disconnected during the 
install, since I put a bunch of stuff there I want to copy to the main 
drive now that the install is finished. I just mount it as needed by 
clicking on it in Caja's Devices list.


--
Regards,

Dick Steffens


___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Ubuntu MATE 18.04 frustrations

[Tomas K]

Great to hear that the file copy problem is out of the way.If you keep
that rsync command in your toolbox, it works incrementally. The next
time you run it, it will only copy new files on the other way. If you
change the source and destination, it will copy new files to the other
machine.

To see your local drive, you will need to mount it.
You said:
>  Can you see it mouted by: mount?
Yes. /dev/sda2 on /

That does not seem to be right - as that is your new installation root
directory.
Can you post output of following commands:
sudo fdisk -l
cat /etc/fstab
Thanks, T



On Tue, May 15, 2018, 8:10 AM Dick Steffens 
wrote:
> On 05/14/2018 11:54 PM, Tomas Kuchta wrote:
> 
> > I do not know what is Caja - G thinks that it is some JavaScript 
> 
> > framework. I doesn't matter anyway.
> 
> 
> 
> It's the GUI file manipulator. Caja is what MATE uses instead of
> Nautilus.
> 
> 
> 
> > I suggest that since you can share to your other machine, you copy
> the 
> 
> > your stuff by rsync from command line.
> 
> 
> 
> I'm more of a visual person, but I am an occasional command line
> user.
> 
> 
> 
> > This should work:
> 
> > cd yourMusicDir
> 
> > rsync -a --progress  rst...@192.168.0.xxx:/home/rsteff/Music/78s ./
> 
> >
> 
> > That should work and show the progress.
> 
> 
> 
> Yes, that is working. (Still has a ways to go, but looks like I
> would 
> 
> expect it to).
> 
> 
> 
> > When you get this out of the way,
> 
> > We can continue on the subject of your local drive access.
> 
> 
> 
> Thanks.
> 
> 
> 
> And yes, spell checkers can turn around and byte you from time to
> thyme.
> 
> 
> 
> 
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Ubuntu MATE 18.04 frustrations

[Tomas Kuchta]

You said that:
a) you cannot copy files from internal disk. True?
b) you are unable to connect to different machine on local network. True?

a) how do you mount that internal disk?
Can you see it mouted by: mount?
b) do you know IP address of both machines?
Try: ip address
Can you connect (ssh) using those IPs?

Tomas

On Sun, May 13, 2018, 2:15 PM Dick Steffens  wrote:

> I got Ubuntu MATE 18.04 installed sometime last week, and am now getting
> around to copying stuff to it. I have a directory with many .mp3 files
> worth of music on a separate SATA drive in the same machine. 27.6 GB. I
> started the copy process using Caja. At first it said it would take
> about 59 hours. (That's when I started typing this message.) Now it say
> it will take about 71 hours at 106.5 kB/sec. Rather than do that I
> decided I'd try copying from another machine, but I can't see any other
> machines, nor can the other machines see this machine. Sigh. Looks like
> I'm changing to an entirely different OS going from 16 to 18.
>
> I've found a few links that indicate networking is done differently now,
> but they're all user experience links. Can someone point me to Ubuntu
> MATE 18.04 documentation that clearly explains how to change what was
> successful in 16.04 so that it works in 18.04?
>
> Thanks.
>
> --
> Regards,
>
> Dick Steffens
>
> ___
> PLUG mailing list
> PLUG@pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

[PLUG] Ubuntu MATE 18.04 frustrations

[Dick Steffens]

I got Ubuntu MATE 18.04 installed sometime last week, and am now getting 
around to copying stuff to it. I have a directory with many .mp3 files 
worth of music on a separate SATA drive in the same machine. 27.6 GB. I 
started the copy process using Caja. At first it said it would take 
about 59 hours. (That's when I started typing this message.) Now it say 
it will take about 71 hours at 106.5 kB/sec. Rather than do that I 
decided I'd try copying from another machine, but I can't see any other 
machines, nor can the other machines see this machine. Sigh. Looks like 
I'm changing to an entirely different OS going from 16 to 18.


I've found a few links that indicate networking is done differently now, 
but they're all user experience links. Can someone point me to Ubuntu 
MATE 18.04 documentation that clearly explains how to change what was 
successful in 16.04 so that it works in 18.04?


Thanks.

--
Regards,

Dick Steffens

___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug