Symlinks work, but don't activate at startup

I created in the terminal symlinks for folders of common directories on a supplemental SSD (four times the storage of system m2 drive) for: “documents”, “pictures”, and “music”.

These DIRECTORY symlinks show in the FILES app at startup, but are not “active”. The “david” symlink created by the system always seems to work fine.

Once I manually access the host SSD as “Other Locations” the symlinks to those devices are both active and work as designed; see “Documents”, “Music”, and “Pictures” where some mount at start-up and some don’t. I’m not catching the determining factor…

How do I make them accessible at startup? Did I do something wrong in creation?

241203_home_symlinks_dir_1B

ALSO (related):
I created symlinks on the desktop to common directory of files (work) and an often accessed .txt file I use for notes… those symlinks DON’T work at start-up, often DON’T work once the directory they connect to is accessed manually, but at some point during the user session, these two items on the DESKTOP present as both “active” and “work as designed”…

I don’t get the disconnect on this one at all. I haven’t seen or figured what “triggers” these desktop symlinks to “activate”.

Any ideas?

1 Like

Ubuntu uses permissions for access.
Hover over folder or sim link, right click,
select properties. Click Permissions tab.
The Access drop-down box: Change from
None to Read & Write, Read Only, Write Only.
This should grant you access.
The startup access problem may be something
completely different.

Here is what is presently set for the desktop “0_System_Maintenance.txt” symlink (shortcut to my notes.txt).

Did you mean set these options up like this?
Owner Access: Read and Write (how it is set presently)
Group Access: Read-only (how it is set presently) and
Others Access: a change from “Read-only” (set) to “Write-only” ?
- for which “write only” is not one of the options
- choices are: [1] None, [2] Read-only, [3] Read and write

Group assigned is to the main [user] group. Should this be set to “root”, a group to which the [user] has also been assigned through the terminal… or does that “higher access” cause rather than solve problems for this function?

and… I find that trying to change the group as the logged in [user], denies access to change the group to “root”. (sigh… the education continues)

241203_symlink_sys_permissions_before

1 Like

I suggest Not to assign any group to Root.
This could lead to escalation of privilege problem.

Owner Access: Create and Delete files
Group Access: According to what group users
need for their tasks. Are they reading the files,
and writing to the files ? Create and Delete Files,
List Files Only, Access Files.
Others Access: How many other users are on
the system? Just owner and groups?
If their is no other users make make this,
“None”

The kernel mounts certain filesystems at boot. If you do

david@davids_computer:~$ more \etc\fstab

You’ll see something like

# /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).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/nvme0n1p2 during installation
UUID=CAFE-BABE /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=CAFE-D00D  /boot/efi       vfat    umask=0077      0       1

That means the kernel is going to scan for disks by UUID and when it finds one that matches CAFE-BABE it will place the content at /

Then it will scan for CAFE-D00D and look for a directory at /boot/efi and slap the content there

You’ll note that your USB disk does not appear in this list, thats because the kernel does not attempt to mount it at boot, instead it is mounted WHEN you click on it in the gui and its mounted into a new directory created on the fly at /media/david/the_volume_name and this directory is owned by David.

Note: If Sam was to log in first, and clicked on the disk then it would be mounted in /media/sam/the_volume_name which would be owned by Sam and David would not be able to access it.

This means that until you trigger the action that causes the mount, the Link you have points nowhere, none of the directory exists.

You can make the drive mount on boot by creating a permanent directory for the mount point and adding a line for it in the fstab.

This post explains how:
https://askubuntu.com/questions/164926/how-to-make-partitions-mount-at-startup

BUT, if its a truly removable drive (e.g. a USB drive), be aware that your system will stall trying to mount the disk if its missing, adding nofail as an option means the system will still boot with it missing, but it will hang there for a bit. This is not a concern if you are talking about a second internal disk.

3 Likes

I suspect that the symlinks are pointing into a mount point where the drive has not been mounted to yet. Thus the target of the symlink does not yet exist. Then at some point later, the disk gets mounted and then the target of the symlilnks pops into existence.

To prove this theory, please open a terminal and issue these two commands, while the links are actually “active” and working, and post the results (include the command you typed so we can check for typos):

lsblk -f | grep -v snap
ls -l ~/Desktop

My own efforts in researching solutions had led me early on to the fstab file. Managing that solution requires skills with the terminal window with which I an unfamiliar, inexperienced, and frankly still need to learn.

My efforts to write to file and append files are met with confusion and frustration. Accurate syntax for command and path with accurate examples to follow are yet another hurdle which has thwarted efforts. To manage fstab entries requires those skills.

This will be my fourth visit to learning how that works among internet contributors, who, each have a different approach, a favorite command, and tend to leave out details which lead me to the command manuals and --help options in attempts to fill in the holes. Some terminal commands I’ve been able to figure out and use, others remain quite elusive.

Appending to system files is one such gaping hole at present, which, I will again try to remedy… as your detailed suggestion seems the most likely and effective solution. I just don’t know yet how to implement that solution; and playing with system files to try to learn them is a bit terrifying.

Thanks for your detailed and informative suggestion; I’ll work on it.

Your analysis seems to match my experience, when the mounted devices are activated, the links then work.

As stated elsewhere in this exchange, the terminal window and commands are not my skill set, but I’m learning as I go. I can identify the commands, even tell you what they do… but the options and syntax to accomplish the same escape me at present. I’ve come across these commands, seeing that they are likely portion to the solution providing pertinent information, but couldn’t figure out syntax to use them.

The drive in question which does not mount at startup, and which activates several of the symlinks once accessed manually is the 2Tb_ExFAt device.

I came back from a workout and noted that the links which don’t activate at startup, seem to activate after the system recovers from “suspend”. I don’t know if that’s the trigger, or why it would be, but it’s as close as I’ve come to a repeatable common condition…

Here is what your command string returns; all links presently “active” as shown:
lsblk -f | grep -v snap
ls -l ~/Desktop

I had assigned “david” [user] to the “root” group in an attempt to solve access issues. Should I NOT have done so… and should I take the trouble to remove the “david” [user] from the “root” group?

What problems does that … invite?

Gives the user more access than it needs. Not recommended. Processes you launch will have the same access as your user, which is in the root group.

1 Like

You are correct to think that changing /etc/fstab without knowing what you’re doing is “a bit terrifying”.

A quick way to generate reasonable fstab entries is to install arch-install-scripts package if you don’t already have it -

sudo apt install arch-install-scripts

Then, when all your symlinks are functional, you can run

genfstab -U /

This command will not modify anything and does NOT need sudo, it will only print a possible /etc/fstab contents for your currently-mounted filesystems.

If you don’t 100% understand the output, do not edit your /etc/fstab right away - to be safe, post that command output here as well as your current /etc/fstab contents for reference, to double check what to actually add to /etc/fstab and just in case the generated entries might benefit from minor tweaking.

1 Like

response updated with image reference for:

lsblk -f | grep -v snap
ls -l ~/Desktop

Good info. The output of ls -l ~/Desktop shows that your two links do indeed point to locations beneath (or inside) /media/david/2Tb_ExFat. That won’t work until the disk gets mounted there.

Your fstab output says that disk is formatted as vfat, not as exfat. Odd.
Specifying type auto should work.

Probably a better place to put drives that are permanatle mounted would be under /mnt (/media is intended for removable media). I suggest /mnt/2Tb_ExFat .
You will need to create this directory before it can be used as a mount point, like this:
sudo mkdir /mnt/2Tb_ExFat
which will mean re-pointing your links on the desktop. I guess you can do that.

My suggested line to append to /etc/fstab, based on that fstab is this:
LABEL=2Tb_ExFat /mnt/2Tb_ExFat auto defaults,nofail,umask=000 0 0
You will probably find gedit easiest to use: sudo gedit /etc/fstab

1 Like

Thanks for the analysis and suggestion. I also find @halogen2 's information and suggestion interesting, though I can’t claim to comprehend it presently.

I sought to format this data drive for access by any operating system. When I installed it and formatted it for use, the information at the time lead me to format it as it is: vFat?. Should it be reformatted for such purpose? I do have several older drives already attached, mounted, and running for archive purposes such as this…

Yes, those suggestions sound feasible and effective, though the thought and consideration of implementing them when I don’t often do this type of work frankly makes my head hurt… ;-D

Yes, I can mkdir and reset the symlinks… I’ll need to revisit how in my notes; yet another project but solvable with what I’ve already learned and applied.

In contrast, I don’t comprehend the following:

My suggested line to append to /etc/fstab, based on that fstab is this:
LABEL=2Tb_ExFat /mnt/2Tb_ExFat auto defaults,nofail,umask=000 0 0
You will probably find gedit easiest to use: sudo gedit /etc/fstab

I get the LABEL item is an fstab entry… no idea what gedit is or does. I’ll have to look into that.

A clarifying question: Where would “auto” be set for the disk format type?

As we uncover and unscramble this pot of spaghetti sauce back to identifiable tomatoes, basil, and garlic, the LONG TERM GOAL is to set up the devices and media to where these are:

  1. formatted for best access and efficiency (vFat / ExFat / ext4)
  2. devices mounted at the proper point (/mnt or /media)
  3. devices mounting at startup as intended
  4. enabling symlinks running as intended

To that end, my poking around with “lsblk” options this morning nets me the following:

The [2] main questions in my mind at this point:

[1] sdb, labeled “2Tb_ExFat” needs be mounted in /mnt rather than /media[user][dir], yes?
Poking around in the directory for “2Tb_ExFat” mount point (dir), that dir contains my archived data. Can I move (mv) this “2Tb_ExFat” directory into /mnt without losing the sub-directories? (of course I’ll backup data prior to trying any of this)

  • I can create a dir/mount point
  • Should I then use “mount” command, or is this done by the OS at startup because it’s now located in the /mnt dir having been moved (mv) there?
  • update of symlinks shouldn’t be an issue once mounted

[2] for the purpose of accessing data from any OS (Linux, Win, MacOS) without having to reformat, is vFat or ExFat the preferred file system type? I used the formatting options in the Ubuntu/Gnome GUI Disks app… and that was the option offered. Should a different file system type be used from the terminal to format instead?

241206_Disks_format_volume_options

AND… is it preferable to back up the data on “sdb” and “nvvme0n1p3” (boot disk data area) reformat these partitions from “vFAt” to “ExFat” (or vice versa) and reset these devices to a preferred file system?

NOTE: sdc is running as intended, sda is [1] windows boot partition and [2] Win-data (ntfs), destined for reformat and re-purpose; not a priority with other data resources available.

Overwhelmed but making progress…

Good info @wiil ; admittedly, it took me days and several re-reads to comprehend it.

Using the “less” command (vs. more) I got a look at what’s in my “fstab” file… thanks. When I figure out how to alter or amend this item I’ll be able to implement the solutions suggested.

I followed the directions for using the “GUI Method” at the above recommended resource and ended up with another issue. While the drives I reset to load at startup now load at startup, all my files are now associated with “root” and logged in as [user] I can’t edit them without saving changes to a new file… So I’m basically locked out of my drive.

How do I fix that?

Since I don’t really know what the operators do, I left them as recommended:

241207_2Tb_ExFat_mount_options

Where it says “nosuid,nodev,…”, append the following (comma-separated) parameters:

uid=YOUR_UID,gid=YOUR_GID

Replace YOUR_UID and YOUR_GID with the numeric values for your user, which you can find by running id in Terminal.

1 Like

Thank you @halogen2; that seems to have worked.

Before I rebooted: I was able to un-mount (pw required, mounted by another user) and re-mount the drives, which now show as properly assigned to the current [user] as well as the current user’s group [group]. I’m curious and will test that it loads AND mounts with the same access privileges upon restart.

It’s amazing that this stuff actually makes perfect sense when clearly explained.

After I rebooted:
[1] My main storage drive mounts at startup, with the current [user] and [group] as intended! [insert happy dance]
[2] The other archive drive isn’t listed among favorites, isn’t mounted at startup, and CANNOT be mounted manually. It worked earlier, but assigned to “root” user and group. It’s settings look the same as the other drive… Did I miss something?

I did check the UUID, mount options; UUID reference is character for character correct.
command: $ lsblk -e 7 -o NAME,UUID,LABEL,FSTYPE,PATH,MOUNTPOINT produces:
sdc /dev/sdc
└─sdc1 fcd7d1ed-edb9-405d-891d-6c6d81bfdb8b WD_1Tb_HDD ext4 /dev/sdc1
(no mount point, won’t mount)

241207_WD_1Tb_access_error_notice
241207_WD_1Tb_drive_mount_options

You’re welcome :slightly_smiling_face:

In /etc/fstab there should be no space around the commas separating the mount options. The fields in an /etc/fstab line are delimited by whitespace, so adding a space there would have pushed the gid=XXXX out of the mount options and into the next field.

I don’t know if the GUI you’re using would have fixed this for you, but in any case, you did well to correct it :+1: