Suddenly cannot access my partitions

Tried reboot doesnot work, but if i log in via E16 DE , works like a charm.
Back to E23 now the whole DE crashes and shows i guess we'll call it the red screen of death which ends with an ecrushdump.txt. Dont know if this can help identify the problem and where it originates. How do i upload a txt file?

I get this feed back

Partition 1 does not start on physical sector boundary.
/dev/sda1 3495999 208734207 205238209 97.9G 7 HPFS/NTFS/exFAT

This results in the partition dissappearing in Thunar file manager

copy it to i.e "gofile" and post the link here. :smile:

Would be interesting to see what E23 has to say why it crashes.

Crashdump for E23

Had a look at it but alas, I'm not acquainted enough with Enlightenment innards to see what is causing what there ..... albeit I have the impression that the crash has not caused by the disk being non-recognized.
It might be EFM (the own filemanager) that's causing some malfunction in the mounting i.e is stricter than Thunar.... I've seen other anomalies there between the two. :thinking:
You could try and disable EFM from the settings panel and see if thunar behaves like in E16 then.

And the question is 'do you find your desired content in ls /mnt?' ...

Lets go with the assumption we have a PAM issue in e23. Please open any terminal, type:
sudo tail -f ls /var/log/auth.log
Now I'm starting with 3-5 times [Enter] to get a gap and see the new lines.

Now try to mount your device in Thunar and we'll see what PAM is trying to do.

I really don't know at this moment howto go on. may we need to take a look at /etc/pam.d/ or /etc/nsswitch.conf ... But why should e23 use any different configuration, than the common one?
To be honest, I'm not using e23.

The only special configuration to use NTFS on-the-fly in Linux is to make sure your user is in the group plugdev. Check your groups with the command id at the terminal.

Even after disabling EFM, behaviour still the same with Thunar

Hi LupusE thanks for joining the rescue effort
Here is my tail output

Okay. The Issue seems to be udisk2. Maybe e16 don't using the udisk2... I've looked into /usr/share/polkit-1/actions/org.freedesktop.udisks2.policy but can't say anything helpful, right now.

Please check is consolekit is installed ($ apt search consolekit |grep consolekit).

E16 works fine. The problem only shows up if i login with E23 as the DE.

The feedback i get is below so I did a sudo aptget install consolekit

Ntfs can be cagey at times, especially if it got disconnected during a file transfer or otherwise abruptly disconnected. So in a way it not mounting is not surprising, especially if it's in use by an existing Windows installation ..... what is surprising is that there's a difference between E16 and E23 there, apparently. :thinking:

The "tail -f /var/log/syslog" output might shed some light as to what the system has to say about the drive when connecting, after which (i.e correcting errors, if need be there) we could look into the differences how either DE handles those situations and whether those are bugs or features.

So let's handle this step by step, from beginning to end.

Tail under E23 after opening partition. Noted that it does not seem to even register here compared to E16 below

Tail under E16 after opening into Partition

im not following very much this thread but... does your partitions are accessible from Live mode? if yes, just reinstall elive to be able to access them again

in fact elive has features for that too (elive has features for everything lol), if you mount them from thunar, check the files inside: /usr/lib/elive-tools/hooks/mount/ , they have not tested in years so not sure if we still having the commands correctly set :wink:

oh wait, it had but not anymore :thinking: , before there was a "fix ntfs if broken" pre.mount hook

I can access the partitions in E16 and Live mode installs E16 which mounts the partitions anyway, just E23 which fails to mount them. I do not want to reinstall the whole OS. I had rather continue using only E16 and give up E23. I really was interested in E23 for bug finding, i will wait for it to fully mature.

I have a suspicion that this is an authetication problem like the one we had earlier with gdebi (the gui program for installing .deb files.) The authentication program/routine in E23 does not link to the mount command to mount the partition when the login password is entered correctly it exits just like gdebi was doing.

I opened a new login account on the computor and amazingly E23 now is able to log into the NTFS partitions from the new account. So i seem to have messed up the login settings for the primary account during update because it still does not log in when i switch back to the old account.

1 Like

Still unable to mount partition in my primary account
I tried mounting through terminal with this command
"udisksctl mount -b /dev/sda2" I got the gui password box, entered the password and then got this message:
Error mounting /dev/sda2: GDBus.Error:org.freedesktop.UDisks2.Error.NotAuthorized: Not authorized to perform operation.

So i repeated the mount command with sudo , entered the password and this time the partitions were mounted. However the contents of the partition cannot be seen in the filemanager. Now i suspect this may be due to an encryption instruction i might have made inadvertently some months back through the freedesktop polkit, policy rules when i was creating my second account on the computor
Below is how my terminal looks with the above instructions. Is someone recognises what a messed up kindly point me to the right way haahaa

We clearly have 2 different things going on here, which are getting mixed.

  1. The (primary as you call it) user has lost some privileges....exactly what and why is not clear but probably self induced through a changed setting.

  2. Thunar in E23 and E16 apparently handles this quite differently, which is strange.

To find out what actually is different it might be worthwhile to compare the 2 users thereand see what is going on.
For instance by comparing the groups both users have access to:
i.e what's the content of /etc/groups ?

As to your output there:
If you mount as root (aka sudo) without giving a path (like /mnt/) it will create a mountpoint in /media/root/ which will not be writeable, and in your case not even readable by a normal user.
Everything is as it should be there, save the authorization issue....frankly, on the commandline no normal user is allowed to mount external partitions whereas the DE does allow auto-mounting.

In your syslog output I saw it was user 1001 that was mounting on E16......So that would be a secondary user. The first user would be 1000 ..... who would that be?

I tried with the path (like /mnt/) and I was surprised it accepted the passwords and opened up the partitions normally on the gui. Now my partitions load up all the time perfectly. This was a long winded way around not the best solution. still cannot tell why the partitions are locked in the primary account

1 Like

Sorry, I was busy the last days with rescuing the world. Until this week I know I am what the German calling 'Systemrelevant'. It seems I'm doing such important things, like the staff in a hospital, the police, firemen or grocery stores....

I would have tested sudo ntfsfix /dev/sda1, but now it is too late.
Since it is sda1, is there a windows system on the disk? So could it be locked during a windows hibernation? In this case you should wake windows and never ever listen to the internet, regarding delete the file hiberfil.sys