[FEAT]: /usr/ is not a good default for data directory root. Change to more sane alternative.

[RlndVt]

Feature Description

As currently implemented here a.o.:

• Cosmos-Server/client/src/pages/config/users/configman.jsx

  Line 121 in 7a3fdfb

  DefaultDataPath: config.DockerConfig.DefaultDataPath || "/usr",

• Cosmos-Server/client/src/pages/servapps/containers/docker-compose.jsx

  Line 213 in 7a3fdfb

  let defaultPath = (config && config.DockerConfig && config.DockerConfig.DefaultDataPath) || "/usr"

From Wikipedia:

Secondary hierarchy for read-only user data; contains the majority of (multi-)user utilities and applications. Should be shareable and read-only.[9][10]

As an example, immutable operating systems have /usr/ implemented as a readonly fs.

I would suggest providing /root/cosmos-server as the default root data directory.

[azukaar]

Hello! And thanks for the suggestion
A subfolder of /root does not work as an alternative as container in the market do not run as root
I dont think there is any "good" folder that matches the desciprtion of a multi-user data folder hence why I jsut settled on /usr

[RlndVt]

Files in /root don't have to be owned by root. Docker (basically root) can create a folder a chown it to whatever is appropriate.

/root is 'just' the home-dir of the root user. Seems reasonable to me to have a sub-folder for cosmos-server (runs as root) nested there for the volume mounts.

[azukaar]

I understand that but I meant to say that ideallogically it does not make more sense

• there isa fundamental issue with users having to traverse non-listable directories to access all their data (since this is a pretty important folder with potentially all your data)
  I used /usr so it wouldnt be in the / but CasaOS for example solved this by simply having /DATA in /

[RlndVt]

I like that your trying to keep / clean.

I see your point about having users be able to access their data. On my fedora system I can't access /root as my normal user. However:

1. Being able to run docker means that you have had sudo powers (or similar) and should be able to use that to access /root (and/or change /root's permissions to do so.)
2. The files that containers create may also be non-traversable. (A container might run as non-root, but limit permissions to files or folders so only the owner(&group) may access; whilst not being the uid/gid of the(/any) user.) This kind of makes it a moot point because you'll need root equivalent rights anyway.

Yet if not under /root, perhaps under /media or /mnt... consider docker volume binds equivalent to 'removable media such as CD-ROMs' or 'temporarily mounted filesystems'. (Not too big a stretch of the imagination.)

[azukaar]

1. yes because you are sudo'd , so you can run docker, but you can't sudo everything, ex. you would lose TAB completion in your terminal
2. 99% of the time the files belong to your non-root user (at least in the Cosmos market;'s container) there are very few exceptions. Keep in minds those files might also be your photos, videos, musics, etc... so keeping them easily accessible is important

I agree that /usr is not ideal

/mnt /media are no go because they trigger special behaviour in Linux counting them as removable media (ex. proposing the user to unmount them etc..)

[sethleedy]

Could you create your own directory on / ?

[azukaar]

Could you create your own directory on / ?

That is probably the best alternative

[chewara]

i recommend /opt