Cannot access USB disk with CLI?? Topic is solved

[viking60]

I have this NTFS USB disk that I use for backup (our backup script). I use Zsh not bash but I am not sure if that matters.
On the 22nd of September the backup stopped running.
And it turns out it is a permission problem.

Code: Select all

media/ LC_ALL=C cd LaCie
cd: permission denied: LaCie


I can access the USB disk with Thunar or PCmanFM so it is there and it is accessible in GUI but not in CLI.


In the CLI I cannot cd into it but it is mounted as /dev/sdb1

Code: Select all

df                     
Filsystem      Størrelse Brukt Tilgj. Bruk% Montert på
/dev/sdb2            30G  381M    30G    2% /run/media/viking/LA-PUBLIC
/dev/sdb1           1,8T  1,6T   284G   85% /run/media/viking/LaCie


So I do suspect some panic bash updates since this occurred at that time - but it could be something else too.

Ho do I get permission to access via the CLI again - it is supposed to be more powerful than GUI - here it is the other way around

It looks like something/program is exclusively opening LaCie (the USB disk) and keeping my shell out.

[viking60]

Aha I think I have found a reason:

Code: Select all

Sep 29 21:26:51 thomas-pc kernel: [27717.755964] Buffer I/O error on device sdb1, logical block 760887
Sep 29 21:26:51 thomas-pc kernel: [27717.755970] Buffer I/O error on device sdb1, logical block 760888
Sep 29 21:26:51 thomas-pc kernel: [27717.755975] Buffer I/O error on device sdb1, logical block 760889
Sep 29 21:26:51 thomas-pc kernel: [27717.755980] Buffer I/O error on device sdb1, logical block 760890
Sep 29 21:26:51 thomas-pc kernel: [27717.755985] Buffer I/O error on device sdb1, logical block 760891
Sep 29 21:26:51 thomas-pc kernel: [27717.755988] Buffer I/O error on device sdb1, logical block 760892
Sep 29 21:26:51 thomas-pc kernel: [27717.755990] Buffer I/O error on device sdb1, logical block 760893
Sep 29 21:26:51 thomas-pc kernel: [27717.755992] Buffer I/O error on device sdb1, logical block 760894
Sep 29 21:26:51 thomas-pc kernel: [27717.755994] Buffer I/O error on device sdb1, logical block 760895
Sep 29 21:26:51 thomas-pc kernel: [27717.755996] Buffer I/O error on device sdb1, logical block 760896


Thank God for error logs
This is a HW problem - with a strange effect though.

I guess if you want an USB disk that last more than exactly three years then you should buy something other than this one

[Snorkasaurus]

I have only had the "pleasure" of dealing with LaCie drives a few times over the years but have never walked away from the experience thinking "Boy, that went well".

S.

[viking60]

Yeah I hear you!
I went to Windows and did some chkdsk routines - and that seems to have taken care of it for now.
I did not have patience to do the 12 hour defrag though

My rsync backup went through nicely after that.

Just for good measure I decided to put it in /etc/fstab so I found the UUID (needed to automount the disk at the same place every time on every connection or when power is turned off and on):

Code: Select all

blkid /dev/sdb1

And that gave me something like:

Code: Select all

/dev/sdb1: LABEL="LaCie" UUID="F91153050041A4371" TYPE="ntfs" PARTUUID="b3ccf74c-01"

So now I had the (UU)ID i could use instead of names in /etc/fstab So I used the UUID and added this line
/etc/fstab

Code: Select all

#/dev/sdb1
UUID=F91153050041A4371 /media/viking/LaCie/ ntfs-3g defaults,auto,umask=000,users,rw 0 0


(the id is faked)

Code: Select all

lsblk -f

Will give a nice overview over the mounts and their structure.

[dedanna1029]

Well, I had something here for you because I'd get this occasionally, but the phone lost the post... I can reconstruct it maybe if you want... it did resolve it for me in a clean way. Guess I will but it won't be the same.

umount the drive (no really), then unplug the USB cable. Reboot without it hotplugged, then once desktop is loaded, plug it back in. If it automounts, check it. It should be fine. if it doesn't at all or if you have to fiddle with it to get it to automount, then you have a cable or drive problem. If it's fine and automounts, you should see a good while before this happens again. In that case, it was some form of glitch.

Not so easy to reboot with a server I know, but for just a few minutes being all that it takes, people can just be patient.