Question on Drive Mounting Points

from shell I did a “lsblk” and got:
login as: root
root@192.168.1.1’s password:

BusyBox v1.23.2 (2016-09-05 13:26:40 CEST) built-in shell (ash)


|__ || | | || __ \ | __ \ | _| / ____|
| | | | | || |
) || |) | | | | (__
| | | | | || _ / | _ / | | ___
| | | || || | \ \ | | \ \ | | ) |
|
| _
/ || _|| _|
||__/

root@turris:~# cd …
root@turris:/# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 1 447.1G 0 disk
├─sda1 8:1 1 100G 0 part /tmp/run/mountd/sda1
├─sda2 8:2 1 345.1G 0 part /tmp/run/mountd/sda2
└─sda3 8:3 1 2G 0 part
mmcblk0rpmb 179:24 0 4M 0 disk
mmcblk0boot0 179:8 0 4M 1 disk
mmcblk0boot1 179:16 0 4M 1 disk
mmcblk0 179:0 0 7.3G 0 disk
└─mmcblk0p1 179:1 0 7.3G 0 part /
mtdblock0 31:0 0 1M 0 disk
mtdblock1 31:1 0 7M 0 disk
root@turris:/# sda 8:0 1 447.1G 0 disk
-ash: sda: not found
root@turris:/# ├─sda1 8:1 1 100G 0 part /tmp/run/mountd/sda1
-ash: ├─sda1: not found
root@turris:/# ├─sda2 8:2 1 345.1G 0 part /tmp/run/mountd/sda2
-ash: ├─sda2: not found
root@turris:/# └─sda3 8:3 1 2G 0 part
-ash: └─sda3: not found
root@turris:/#
root@turris:/#

So the new SSD ext4 & NTFS partions mounted to /tmp/run/mountd/

Why a “tmp” here. It’s an internal drive. Would we want it mounted to “/mnt/sda1” and /mnt/sda2" ???

It mount automatically to “/tmp/run/mountd/” how do we change this behavior and the internal SSD mount to “/mnt/”???

What do you see in System | Mount Points | Mounted file systems?

One section below it is Mount points. You can change the mount point there, click the Edit button and its the Mount point dropdown. Do not forget save changes and remount the drive.

Where the 1st location SYSTEM located. LUCI, Fortis, Shell prompt?

Ah in Luci:

Mounted file systems
Filesystem Mount Point Available Used Unmount
/dev/mmcblk0p1
/
7.16 GB / 7.28 GB
2% (123.44 MB)
tmpfs
/tmp
1009.31 MB / 1011.23 MB
0% (1.92 MB)
tmpfs
/dev
508.00 KB / 512.00 KB
1% (4.00 KB)
/dev/sda2
/tmp/run/mountd/sda2
345.04 GB / 345.13 GB
0% (96.79 MB)
Unmount
/dev/sda1
/tmp/run/mountd/sda1
88.70 GB / 93.71 GB
0% (8.00 KB)
Unmount
Mount Points
Mount Points define at which point a memory device will be attached to the filesystem
Enabled Device Mount Point Filesystem Options Root Check

UUID: 42ac4bfa-fd29-427a-9b85-b8c45f3317e5 (not present)
/mnt/sda1
?
defaults
no
no

OK I see I can unmount them in Mounted file systems.

I see in MOUNT POINTS that sda1 has an UUID but its not enabled. BUt I don’t see a UUID for sda2.

How are we getting the UUID #'s in terminal???

lsblk -o NAME,UUID

You don’t really need it, though. You can use device name (/dev/sda1), you don’t have to use UUID necessarily.

Now “blkid” from busybox gives me this:

root@turris:/# blkid
/dev/mmcblk0: PTUUID=“5ae73b10” PTTYPE=“dos”
/dev/mmcblk0p1: UUID=“3a6fa6a7-16d5-4178-96f6-655f342318f2” UUID_SUB=“3a35d335-064e-439c-b26d-60b7615a7517” TYPE=“btrfs” PARTUUID=“5ae73b10-01”
/dev/sda1: UUID=“1cbfffe5-cc49-d201-100e-e4e5cc49d201” TYPE=“ext4” PARTLABEL=“Basic data partition” PARTUUID=“e5e40e10-49cc-01d2-0807-f272e624e900”
/dev/sda2: LABEL=“SAMBA_FTP” UUID=“01D249CD83DDA4F0” TYPE=“ntfs” PARTLABEL=“Basic data partition” PARTUUID=“8e995fb0-49cd-01d2-d8af-0cc1e624e900”
/dev/sda3: TYPE=“swap” PARTLABEL=“Basic data partition” PARTUUID="37f77db0-49cf-01d2-d8ba-7b82e724e900"
root@turris:/#

Don’t see the current UUID for sda1 on the list generated by blkid. And only sda1 has a UUID. The partitions all have PARTUUIDs

Can "PARTUUID be also be used for the “UUID” entry?

Looking at the the blkid ouput Sambe seems to already be using sda2 automativcally. I didn’t attach it.
I delete the two /tmp/ sda’s above and remake below is that going throw Samba a fit?

delay that samba ? that just a label I made on parting and format of the drive

Ok /dev/sda1 is now mounted to /mnt/sda1

Now I have issue with /dev/sda2. It not option on the mounting lists and it didn’t have UUID.
It was mont to /TMP/ before i deleted it above.
Now sda3 is on list. Just not sda2

Hmm?? I partitioned in Minitool on Win7 as NTFS for samba compatibility between Windows and Linux.
Might have done something wrong here or missing small pretask to get it to appear on the list?

Hmm lsblk does show sda2 with number for UUID however the number not normal looking to me

? 01D249CD83DDA4F0

That does not look like your typical UUID.

Do we got load an ntfs3g package or something hear to mount the sda2 NTFS Partition?

So. That’s a no since it already installed and having the issue hear.

UUID is file-system specific. Yet, NTFS one is different. So is FAT’s (XXXX-XXXX).

You don’t need NTFS for samba - samba is a network protocol, it does not care about on-disk layout. You need NTFS only if you want to connect the drive physically to a Windows machine. Otherwise, it’s better to use ext4 or other native linux filesystem.

I also had an filesystem not listed there - the reason turned out to be, that it was formatted using xfs and the chooser didn’t list xfs partitions. Reformatting to ext4 solved that.

it not the network protocol that my concern. It’s file name rules, lengths, permission standards and etc.

I still don’t see why can’t mount the ntfs partition. Windows 7 should use a normal uuid. Tmp had automounted it before.

ah maybe just maybe this is the issue.
the msatas were old drives from the mini computers. and previously GPT no MBR.

MBR would allow 4 primary partition. ie UUIDs, Plus OpenWrt write says it only knows MBR not GPT.

Guess i should delete it. remake MBR?

Ya but UUID are something GPT brought in to the picture. That doesn’t make sense. LUCI using UUIDs.

GPT is not a problem, Omnia can both read and create GPT partitions.

If you don’t want to fight with luci and you know exactly what you want, check your /etc/config/fstab file. You can use option device '/dev/whatever' and option fstype 'whatever', so you are not limited to what uci can detect.

Regarding file name rules: it does not matter. There’s slight mismatch, and even on Windows, NTFS and WINAPI have slightly different rules anyway (you may end up with file, created in Windows, that Explorer can not read). For most people, ACLs are more trouble than worth and just define access on shares, not on files. You cannot share ACLs between linux and windows machine, unless you have a domain controller, that maps your SIDs to users, because both machines will have a different idea, which SID is which user. And finally, by using NTFS in Linux, you are going to pay the price in performance: ntfs3g is a fuse-based filesystem.

UUID are not something that GPT brought into picture. Filesystems had unique IDs as far as FAT12 on floppies. They were not called UUID then, they were Volume ID :wink: