Symlinks no longer working properly + Permission issues

General system Newbie
1

I’m prefacing this by admitting that I’m a complete imbecile and this is entirely my fault. I’m terribly sorry, please don’t hate me for messing this up.

As some of you know, I’ve previously been dealing with severe GPU under-performance and overheating, and one of my attempts to fix it was switching to a different distro (Fedora KDE initially; later switched to Cinnamon) to see if the issue could be isolated to EndeavourOS. It’s since been solved, but I’ve unwittingly done a major screw-up while on Fedora KDE that’s come to bite me today.

I have two drives - a 480 GB SSD (/dev/sda) that serves as my primary boot drive, and a 4 TB HDD (/dev/sdb) that serves as my secondary storage where I can put all my super heavy files into. While switching distros (from Mint to Endeavour to Fedora and back to Endeavour), I always put the files I wanted to carry over onto the HDD so they could easily be loaded directly into the new distro - which was particularly important considering I needed to do benchmarking on Steam. I generally use GNOME Disk Utility to set up my drive’s mounting options, but on KDE I wanted to try and use its native Qt apps instead of GTK ones, and decided to try it out. It, uh, didn’t go well, to put it lightly - maybe I’m just unlucky, but it was horribly buggy for me and even broke my fstab file entirely, forcing me to fix it from a live USB.

Compounding that, there was… an incident. I generally always mounted my drive on /home/tadpole/Secondary Volume because it’s just easier - it’s much simpler to access than having to go up to root and look up one of the several folders a drive can be mounted to (/mnt, /media or /run), not to mention you don’t have to deal with permission nonsense since, unlike the aforementioned folders, ~ isn’t owned by root for obvious reasons. However, while I was asking for help regarding the broken fstab issue in a server, someone asked me where I was mounting the drive, and when I revealed I mounted it on home he basically raged at me, saying that’s not how I’m supposed to do it and any actually decent Linux user would never mount a secondary drive on ~, asking why he even bothers dealing with noobs asking for help and saying “people like you are why I have gray hairs” and “I need a freaking drink after seeing this”.

That pretty much scared me into choosing to mount my drive onto /mnt/Secondary Volume instead, since I didn’t want to get further yelled by anyone else and also got worried it was a terrible idea to mount my drive on ~ and it’d be safer to put it on /mnt instead. Sadly, that turned out to cause more issues than I’d like - in particular, as I mentioned, putting it outside of ~ requires mounting it on a folder owned by root, meaning my entire hard drive was read-only and completely owned by root:

image

When I asked for help, I was told to run chmod -R +x /dev/sdb1, and it seemed to work, so I just brushed it aside and moved on to trying to resolve my GPU issues. But today, after I migrated back to EndeavourOS upon resolving the aforementioned issue, I noticed several irregularities regarding my hard drive…

For starters, when configuring CinnVIIStarkMenu, there were multiple folder locations on my HDD the Quick Launcher seemingly refused to recognize - they exist on my hard drive and I can look at them through my file manager, but when inputting its location on the menu’s own file browser to add a shortcut there, it acts like the address is not valid at all and the shortcut does not show up. And next up, this issue does not seem to be limited to actual locations: symlinks seem to not work, either.

I make heavy usage of symlinks on my workflow; I use them to make quick shortcuts on my main drive and desktop to folders on my HDD that I use often, as well as “placing” mod files within the Proton prefix of a Steam game so that the game reads it, without having to leave them inside a location that is both tiresome/convoluted to get into, and also vulnerable to getting nuked if I uninstall the game or change to a different Proton version. I’ve done that with Euro Truck Simulator 2 for a while now; symlinking a mod folder within its Proton prefix to another location on my hard drive that’s easier to get into has always worked without a hitch. But, for whatever reason, it suddenly stopped working - the game straight-up refuses to acknowledge I have any mods installed other than Workshop mods, unless I actually place the real files inside the Proton prefix itself. (And even then, the game just crashes when it finishes loading.)

Lastly, several files and folders have weird, possibly buggy permissions on them. Instead of them belonging to the “tadpole” group like all my files on ~ in my SSD do, several random files and folders instead belong to a “1001” group:

image

For reference, this is how pretty much all my SSD files are:

image

Because I never tampered with my HDD at all during my distro finagling from before except for me mounting it on /mnt instead of ~ and running the chmod command, I’m confident that these issues can be isolated to those having screwed my HDD files - it doesn’t help that someone just told me that apparently running that chmod command is… not ideal. :confused: Issue is, I still don’t understand how permissions work on Linux, or what I could do to rescue my filesystem from this screw-up (if it’s even possible to do so at all - I’ve been told it’s incredibly difficult to revert a chmod -R +x /dev/sdb1…), or hell, if all this is even related to my symlinks suddenly not working anymore.

I’m sorry for once again clogging the forums with an idiot question, but I’m quite scared and really need help in dealing with this. I really don’t want to have to resort to nuking my HDD partition and starting over from scratch :c

2

In short, your HDD files are in permission hell. The things you did in Fedora seem to have carried over to eos. Your problem needs a few specialists (I’m not one of them).

@dalto, and @ricklinux hope you guys can help here.

3

I mount several of my drives to various paths inside my /home directory. There is absolutely nothing wrong with doing that, in fact, I would say it’s a perfectly logical place to mount that drive, assuming that it really belongs in your user space (meaning: you are the only user who uses that drive and you own all files on it). It’s an entirely sensible thing to do, and it is precisely done to avoid this permission mess that you’re in right now.

I guess that makes me an indecent Linux user. rofl

Anyway, you should not be taking advice from people who are impatient with you and treat you like s:poop:t, because more often then not, you’ll get bad or incomplete advice.

Running chmod with the -R option is generally terrible. Whenever you think you have to change permissions on a large number of files (using the -R option), you should always stop and think… And, hopefully, conclude that this is a really stupid idea, that a lot of things can break and that it is pretty much impossible to reverse it. Personally, I think it was a bad idea by the POSIX standard to even include the -R option in chmod, as I’m sure that option created more pain than gain (and if there is really the need to recursively change permissions, there are other, less straightforward ways to do it).

Fortunately, whoever told you this probably didn’t know that /dev/sdb1 is not a directory, but a device file, so -R is entirely ineffective on it and you probably haven’t done too much damage.

Regarding symlinks, they stop working whenever you move a file (or change path to it). You can test for a symlink with the file command:

file your_symlink

And it should print:

your_symlink: symbolic link to path_to_where_you_linked_it

If that path does not exist, your symlink is broken and you have to either relink it, or restore the path.

Alternatively, you can do ls -la to see where symlinks point.

My advice is to edit your fstab and remount your drive to the previous location it was in, within the /home directory. This may automatically fix a lot of symlink issues (so you don’t have to relink everything manually).

After you do that, we can see whether there are any permission issues.

Please also show the output of

ls -l /dev/sdb1
4 Likes
4

Yeah, I really regret having done that and really hate myself for having caved in and done that. My previous setup worked just fine, I didn’t have to be a freaking idiot and change it just to accomodate some elitist snob on the internet. At least I learned my lesson and won’t do that again in the future, I suppose. I just hope I learned it the easy way and this mistake can be easily rectified…

Actually, I was aware of that and already manually recreated all my symlinks when I mounted my device on /mnt, and further recreated them again when switching back to Endeavour and ran into the issues with the symlinks not being recognized. For example, running the file command on a symlink StarkMenu seems to refuse to recognize returns:

tadpole@Sanctuary:~$ file ./Desktop/'Pictures, Junk, etc'
./Desktop/Pictures, Junk, etc: symbolic link to /mnt/Secondary Volume/Desktop Files/Pictures, Junk, etc

So the issue is not broken symlinks. They work just fine and flawlessy when accessing them through Nemo (the Cinnamon file browser), it’s just my computer applications (including Proton games) that refuse to acknowledge the symlinks exist no matter how many times I recreate their symlinks, despite them having always worked just fine before. And it’s only for some random folders, while others work just nicely. Case in point, StarkMenu recognizes the following symlink just fine:

tadpole@Sanctuary:~$ file ./Desktop/Games
./Desktop/Games: symbolic link to /mnt/Secondary Volume/Desktop Files/Games

So it’s probably not that.

As for the ls command:

tadpole@Sanctuary:~$ ls -l /dev/sdb1
brw-rw---- 1 root disk 8, 17 Jan 14 10:09 /dev/sdb1
5

it’s because people like them why I have grey hair
:older_adult:t5:

6

Looks good to me :sunglasses: So that chmod -R +x probably did not change anything.

Is there a difference in permissions?

Normally, directories should be drwxr-xr-x and normal (non-executable) files are typically -rw-r--r-- (though, of course, this can vary, depending on the use cases).

Symlinks have lrwxrwxrwx, but the access depends on the linked file, not the link itself.

It’s really difficult to track and reverse all the changes you’ve made, having relinked all the symlinks manually. Now, if you want to mount the drive back into your /home directory, you’ll have a total mess with symlinks again. :man_facepalming:

As you have figured out by now, it’s not a good idea to change the mount point of a permanent storage drive on a working system. That’s all right, it’s all part of learning…

1 Like
7

This is the result of running ls -l on my Desktop files (aka their symlinks):

tadpole@Sanctuary:~$ ls -l ./Desktop
total 12
-rwxr-xr-x 1 tadpole tadpole  313 Jan 11 22:43  discord.desktop
lrwxrwxrwx 1 tadpole tadpole   41 Jan 12 14:13  Games -> '/mnt/Secondary Volume/Desktop Files/Games'
lrwxrwxrwx 1 tadpole tadpole   41 Jan 12 14:13  Music -> '/mnt/Secondary Volume/Desktop Files/Music'
lrwxrwxrwx 1 tadpole tadpole   55 Jan 12 14:13 'Pictures, Junk, etc' -> '/mnt/Secondary Volume/Desktop Files/Pictures, Junk, etc'
-rwx--x--x 1 tadpole tadpole 7491 Jan 11 17:47  steam.desktop
lrwxrwxrwx 1 tadpole tadpole   45 Jan 12 14:13  Utilities -> '/mnt/Secondary Volume/Desktop Files/Utilities'

And this is the result of running it on their actual location (i.e. not symlinks):

tadpole@Sanctuary:~$ ls -l /mnt/'Secondary Volume'/'Desktop Files'
total 24
drwxrwxrwx 13 tadpole tadpole  4096 Jan 12 14:15  Games
drwxrwxrwx  2 tadpole tadpole  4096 Jan 12 14:13  Music
drwxrwxrwx 29 tadpole tadpole 12288 Jan 12 23:57 'Pictures, Junk, etc'
drwxrwxrwx 11 tadpole tadpole  4096 Jan 12 14:13  Utilities

For comparison, this is the result of running the same command on folders within my main SSD drive that were formed only on my fresh EndeavourOS installation:

tadpole@Sanctuary:~$ ls -l ./.local/share/'Paradox Interactive'
total 16
drwxr-xr-x  2 tadpole tadpole 4096 Jan 13 18:41 'Crusader Kings II'
drwxr-xr-x 12 tadpole tadpole 4096 Jan 13 19:43 'Europa Universalis IV'
-rwxr-xr-x  1 tadpole tadpole   30 Jan 13 18:40  launcherpath
drwxr-xr-x  4 tadpole tadpole 4096 Jan 13 18:40  launcher-v2

All of these are folders, except launcherpath, which is a file.

8

Hmm… Why not drwxr-xr-x like everywhere else? Have these files/directories been copied from a NTFS partition? Regardless, that’s clearly not the issue…

Well, yes, if it were a directory, it would start with d instead of - :wink:

These all work? Or some of them do not work and some do? We have to figure out what is different in those that work and those that do not work.

9

Sorry for going OT but I’ve to say this. I was wondering why our own Frog was very helpful in here. And then I realized he should be OP is a Tadpol.

1 Like
10

Amphibians got to stick together :stuck_out_tongue:

Yes, many of those files are holdovers from my Windows 10 days, as such they were originally created on an NTFS-partitioned drive. (I’m not currently using NTFS anymore, don’t worry)

I’m confused as to why this is happening, then… maybe it’s not a writing permission but rather a group permission issue? I mean, I still have files that belong to “1001” for some reason;

tadpole@Sanctuary:~$ ls -l /mnt/'Secondary Volume'/'Backups - Manual'/'Euro Truck Simulator 2'
total 12
drwxr-xr-x 2 tadpole tadpole 4096 Dec 29 22:50  mod
drwxr-xr-x 2 tadpole tadpole 4096 Dec 21 22:32  music
drwxr-xr-x 8 tadpole    1001 4096 Jan 13 18:14 'pfx - documents'

For whatever it’s worth, this is what happens when running it on the main directory of my drive:

tadpole@Sanctuary:~$ ls -l /mnt/'Secondary Volume'
total 40
drwxrwxr-x 10 tadpole tadpole  4096 Jan 11 17:19 'Backups - Manual'
drwxrwxr-x  6 tadpole tadpole  4096 Jan 12 14:14 'Desktop Files'
drwxrwxr-x  8 tadpole tadpole  4096 Jan 13 14:01  Downloads
drwxrwxr-x  4 tadpole tadpole  4096 Dec 25 16:43 'Game Installations - Lutris'
drwxrwxr-x 10 tadpole tadpole  4096 Dec 14 18:09 'Game Installations - RetroArch'                                                                               
drwxr-xr-x  3 tadpole    1001  4096 Jan 14 01:38 'Game Installations - Steam'
drwx------  2 root    root    16384 Dec 14 15:41  lost+found

All those files are holdovers from way back and have gone through my permission fuckery.

11

Nothing should belong to this 1001 group. Your user’s group (tadpole) is probably 1000. Can you post the output of cat /etc/group, just to check?

I’m beginning to think there is nothing wrong with permissions, but something else is at play here… You should check all your config files for programs that have problems: perhaps you still have in some of them the full path with the old mountpoint (generated automatically, perhaps).

Also, look inside the .desktop files for exec= lines, maybe they contain full paths to the old mountpoint inside /home?

This is not the cause of this problem, but you should fix these permissions (do not do it recursively, though).

12

I think it would be worthwhile to chown the items that show 1001 back to your control properly. Perhaps they were messed with by ‘another user’ along the way. Back in early Garuda they had a default of 1001 for the primary user - and that could be fun to fix (especially on files that were accessible from multiple locations! :grin:). I don’t know that it is related to the current problem though…

13

It could be that Fedora has 1001 for the primary user’s group by default? I have no idea. EndeavourOS should have 1000… So could it be that these files were made on Fedora, with the same user name, but a different group?

In any case, that should be fixed, yes. But I don’t think it’s the cause of these issues…

14

Yeah - pretty likely I guess - but it’s been awhile since I ran Fedora on anything! Something about ‘discovering’ Arch wasn’t as hard or as breakable as the rumours would have it…

15

I got this:

tadpole@Sanctuary:~$ cat /etc/group
root:x:0:root
sys:x:3:bin,tadpole
mem:x:8:
ftp:x:11:
mail:x:12:
log:x:19:
smmsp:x:25:
proc:x:26:polkitd
games:x:50:
lock:x:54:
network:x:90:
floppy:x:94:
scanner:x:96:
power:x:98:
nobody:x:65534:
adm:x:999:daemon
wheel:x:998:tadpole
utmp:x:997:
audio:x:996:
disk:x:995:
input:x:994:
kmem:x:993:
kvm:x:992:
lp:x:991:cups
optical:x:990:
render:x:989:
sgx:x:988:
storage:x:987:
tty:x:5:
uucp:x:986:
video:x:985:
users:x:984:tadpole
systemd-journal:x:983:
rfkill:x:982:tadpole
bin:x:1:daemon
daemon:x:2:bin
http:x:33:
dbus:x:81:
systemd-coredump:x:981:
systemd-network:x:980:
systemd-oom:x:979:
systemd-journal-remote:x:978:
systemd-resolve:x:977:
systemd-timesync:x:976:
uuidd:x:68:
locate:x:21:
ntp:x:87:
avahi:x:975:
named:x:40:
colord:x:974:
dnsmasq:x:973:
git:x:972:
lightdm:x:971:
nbd:x:970:
nm-openvpn:x:969:
openvpn:x:968:
polkitd:x:102:
rpc:x:32:
rtkit:x:133:
usbmux:x:140:
tadpole:x:1000:
cups:x:209:
deluge:x:967:

There is indeed no 1001 group, and my group is listed as 1000.

I couldn’t really find any references to the /home mountpoint as I throroughly edited everything to reference the newer mountpoint. And besides, I actually made a symlink to my /mnt/Secondary Volume directory as /home/tadpole/Secondary Volume post-Endeavour installation, so I highly doubt it’s an incorrect path.

Additionally, I tried reinstalling ETS2 onto my SSD (not merely relocating it; I outright uninstalled the game and reinstalled it on my SSD to eliminate any margin for error) and then re-created a symlink on its Proton prefix to /mnt/Secondary Volume/<directory of my ETS2 mod files, and the game still didn’t recognize them, even though I’d done this in the past and it worked just fine.

How would I do any of these, especially not recursively?

16

To fix the 1001 group:

chown tadpole:tadpole path/to/file_or_directory

To fix the 777 (drwxrwxrwx) permissions (copied from NTFS):

chmod 644 path/to/file

chmod 755 path/to/directory

Files should be normally -rw-r--r-- (644) and directories drwxr-xr-x (755), but when you copy something from NTFS, it can become drwxrwxrwx (777).

1 Like
17

Will I have to do all that manually, for every single file and folder?

18

You can automate it, but you have to be very careful. There is no undo, so you can break permissions of executable files, and permissions you’ve set manually before for some files.

19

What are the risks? And what can I do to pull this off in a safe way? Are those risks also present for the chown command, or can I do it recursively on my HDD without issues?

20

That really depends. There is no simple universal answer.

If your entire drive is part of your user space, then it makes sense for you to own all files in it. Sometimes, however, you may have a good reason to for some other user to own some file, even in your home directory.

You could do it with something like this:

find "~/Music" -type f -exec chmod 644 {} \;
find "~/Music" -type d -exec chmod 755 {} \;

For example, if you’ve copied a bunch of music files from an NTFS drive, this will set the permissions of all directories inside ~/Music (and inside any subdirectories in that directory) to 755 and permissions of all files to 644 (again, in the entire directory tree). However, if you have any files and directories where you want different permissions (for example, executable scripts), those will also get changed. This is unlikely to be the case in a directory like ~/Music, but in some other directory like ~/Programming/Scripts it may be an issue.

And you can fix the 1001 group with:

find "~/Music" -group 1001 -exec chown tadpole:tadpole {} \;

If you run this, there will be no files or directories owned by the 1001 group inside the directory tree starting with ~/Music (again, just an example), they will all be converted to tadpole. This one should be fairly safe to run, even on your entire home directory (but still, there is no warranty).

However, I don’t think this will fix your symlink issue. I still have no idea what caused it. Can you explain the problem in more detail? In what way do programs fail to respect the symlinks?

1 Like