.wine is not owned by you

[ajackson]

"the way THEY want it" sounds SO microsoft.

Is this your tin-foil hat?

[Diskdoc]

I have a Edubuntu terminal server setup with the home-directory of every user containing a symlink to /home/test/.wine where the needed wine-config is stored. I came up with this as a way to make managing the wine regs easier (only user test has write access to the config files).

After upgrading to Hardy this no longer works since the symlinks are root-owned and Wine complains just as noted by others in this thread. I tried replacing the symlinks by hard links but directories aren´t allowed to hard link.

Can any of you help me get around this new security measure in Wine? A good idea, I´m sure, but for me it messed things up needlessly.

[Enverex]

Well those users can't write to something owned by the other user anyway which will just break Wine sooner or later (and more likely the former than the later). Wine is not designed to be multi-user.

[Diskdoc]

That may be but until now it has worked nicely. The applications needed are old and quite simple Windows 3.x or 9x educational tools. The problem here is the "owned by root"-security measure, not Wine not being designed to be used by multiple users.

I realise it is possible to edit the code and compile for myself but I´d rather like some other solution that´ll do the job for me. The goal for me is:

- Not having to copy and overwrite every .wine directory for every user every time I add an application (using the "test" user).

[iseeuu]

The only thing you'd need root access to do in Wine is host servers at ports under 1024, since those are reserved for root on Linux systems. Just pick a higher port for now.

As for niceness levels, you can run the renice command as root without making the process itself run as root.

OK!.........My head is hurting from trying to get a handle on "permissions". Either the room is spinning or I am.

I have spent most of the last 24 hours (with only a little sleep) getting a win32 app to have access to the Internet. I finally did this morning: I had to go the "backport" route to get version 1, manually install all dependencies, and reinstall wine a couple of times. Oh, sorry, head still spinning, on a Debian etch box. I was so elated to have beat the technology that I decided to get my wine app to start at bootup. No problem! I can use "KSysV", from my KDE desktop, and/or "Webmin" "Bootup and Shutdown" utility.

Problem: I installed wine as me, a regular user, and now wine refuses to work unless user "Me" starts it. However: "init.d" refuses to start wine unless "root" starts it!! Ooww... my head. So how do I use wine as "Me" and still get my app started at bootup? Can I give it root ownership, and run it as another user (in KDE)? Or do I give it "Me" ownership and run the init.d script as "root"?

It is obvious to me that I have missed a simple connection somewhere. I get so confused!

Any ideas?

[cogadh]

Instead of trying to launch it every time the system boots, launch it at login. Create a .bash_login file in your home directory with your Wine commands in it. The commands in that file get run every time your user logs in.

[iseeuu]

Instead of trying to launch it every time the system boots, launch it at login. Create a .bash_login file in your home directory with your Wine commands in it. The commands in that file get run every time your user logs in.

Now that sounds to easy. I was not aware of this function. You wouldn't have a link to a "how to do this"?

[cogadh]

Actually, now that I think about it, I don't think Ubuntu uses a .bash_login file, it uses a .profile file, which is really the same exact thing. You should already have one in your home directory, just open it with a text editor and add your wine commands to it.

[iseeuu]

Actually, now that I think about it, I don't think Ubuntu uses a .bash_login file, it uses a .profile file,

I have three files in my home directory:

.bash_logout

# ~/.bash_logout: executed by bash(1) when login shell exits.

# when leaving the console clear the screen to increase privacy

if [ "$SHLVL" = 1 ]; then
[ -x /usr/bin/clear_console ] && /usr/bin/clear_console -q
fi

.bash_profile

# ~/.bash_profile: executed by bash(1) for login shells.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/login.defs
#umask 022

# include .bashrc if it exists
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi

# set PATH so it includes user's private bin if it exists
if [ -d ~/bin ] ; then
PATH=~/bin:"${PATH}"
fi

.bashrc

# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

# don't put duplicate lines in the history. See bash(1) for more options
export HISTCONTROL=ignoredups

# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize

# make less more friendly for non-text input files, see lesspipe(1)
[ -x /usr/bin/lesspipe ] && eval "$(lesspipe)"

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
xterm-color)
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
;;
*)
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
;;
esac

# Comment in the above and uncomment this below for a color prompt
#PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD/$HOME/~}\007"'
;;
*)
;;
esac

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

#if [ -f ~/.bash_aliases ]; then
# . ~/.bash_aliases
#fi

# enable color support of ls and also add handy aliases
if [ "$TERM" != "dumb" ]; then
eval "`dircolors -b`"
alias ls='ls --color=auto'
#alias dir='ls --color=auto --format=vertical'
#alias vdir='ls --color=auto --format=long'
fi

# some more ls aliases
#alias ll='ls -l'
#alias la='ls -A'
#alias l='ls -CF'

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi

Should I edit one of these files, or should I create and use a .bash_login file?

I use Debian Etch, but I have found more solutions here on the Ubuntu Forum than anywhere else. Thanks

:})

[cogadh]

I wouldn't add it to the .bashrc, if you do that, it will run it every time you open a terminal. Adding it to .bash_logout would also be useless, since that only runs as a user logs out. I don't remember if .bash_profile is another alias for .bash_login. I would just create either a .bash_login or .profile in your home directory and add it there.