AllowRoot=True - does it work in Jaunty?

[DGeeez]

I had trouble viewing non-system partitions on my drive through nautilus, and gksudo nautilus has never displayed links to these other partitions without me browsing them through nautilus first. That sounds strange, maybe dumb, but that's what I was getting, and for some reason I just wasn't able to get any response at all when I clicked the icons which Nautilus displayed. gksudo, or sudo nautilus do not display as quite the same browser guis, and some of the icons and buttons displayed in nautilus are either nonexistent or they yield errors (the Computer button is an example of the latter).

The only cause which I could consider at the time was my non-root status, and that maybe nautilus (which at least gave some indication that it knows my other partitions exist, in displaying the icons which I can't see in gksudo nautilus) may give the full access which I needed on my own machine if I was able to run that specific gui while logged in as root. I run Jaunty,

The solution which I tried was not my own idea, and it's nothing I or most (so it seems) would recommend. I cannot post links here, and wouldn't want the apearance of promoting it here anyway, but what I did was simply change the AllowRoot=False line in my gdm.conf file to AllowRoot=True. This fix would implicitly allow the root to login after a reboot. Well, I don't know if this ever did cause me to run a root session, but when, after saving the change and rebooting, I was able to view, but not write to those partitions in question through nautilus, and after opening them for viewing, I could get full access to them through gknautilus (which previously didn't even indicate they existed) - this is why I thought at first that the change must have worked, and I had logged in as user.

Well, there's something else. At some point a few months ago, I decide that I didn't like logging in to my home PC, so I took the option to make the process automatic. Now I have my AllowRoot variable set to true, and I wonder if that could possibly have allowed my root user to log in at system startup without any input from me, or even my seeing it, and then if it failed to do so then I wouldn't have known that either. So, I suppose I should disable the automatic login, if I can dig up how to do that. Still, my nautilus access, which changed after I changed one variable from false to true, and did not change back after I reset that variable back to false. Also, I had to use sudo to save changes while I thought that I was in root mode. So, maybe root access has nothing to do with the failure of nautilus to display or provide access to certain media.

In summary, my two questions are

1. Is AllowRoot=True in the gdm.conf file effective in Jaunty?
and
2. If it isn't root access, or lack of it which caused my partition access problems (they are ext3), then what else may cause this?

[coopstah13]

a root session will only be started if you explicitly login as root at the gdm login screen, also for automatic login, the user must be specified, and if it wasn't specified as the root user, then that wasn't the user that was automatically logged in

[reed9]

gksudo, or sudo nautilus do not display as quite the same browser guis, and some of the icons and buttons displayed in nautilus are either nonexistent or they yield errors (the Computer button is an example of the latter).

I don't use GNOME, and I'm not too familiar on how it handles network partitions, but I do use a program called gigolo to handle network connections, and it borrows from the GNOME method. I believe what it happening here, is that network partitions are mounted under /home/$USER/.gvfs. When you run nautilus as root, it would then look under /root/.gvfs and not finding anything, would give you an error message.

what I did was simply change the AllowRoot=False line in my gdm.conf file to AllowRoot=True. This fix would implicitly allow the root to login after a reboot. Well, I don't know if this ever did cause me to run a root session, but when, after saving the change and rebooting, I was able to view, but not write to those partitions in question through nautilus

As said, you still have to log in as the root user. It will not automatically log you in. Which means typing in root as the username, and then the root password. Since Ubuntu has the root password disabled by default, unless you had set a true root password previously, I doubt you actually were logged in as root. It may be that you can set automatic login for root with GDM, as you would for any other user. I don't know. Did you open the GDM config utility and set it to auto-login?

I'm unclear what you mean by non-system partitions. You mean partitions that aren't defined in /etc/fstab? It sounds like either the partitions were mounted read only, or the permissions/ownership was incorrect.

[DGeeez]

I'm unclear what you mean by non-system partitions. You mean partitions that aren't defined in /etc/fstab? It sounds like either the partitions were mounted read only, or the permissions/ownership was incorrect.

I just mean partitions which I'm not running my current operating system, partitions, partitions which don't have any operating system at the moment, but their mine, and I currently use them to warehouse my files while deciding whether to try another distro or eventually expand Ubuntu over my whole disk (reasons for doing so do not include the official distro site support). There must be a better term of reference, but I just couldn't find one.

Also, yes, the partitions do appear to be mounted read-only - I could not move files to them. This is how nautilus is working when I'm not running it gksudo, and I'm wondering if this is normal. There have previously been sessions when nautilus could not access my partitions at all (which made gksudo useless for this purpose as well, maybe because of the operating loop which you referred to. I sure would like to sort out why it behaved the way it did, and why it does what it does now - anyway, should a normal logged in user expect to see all partition drives displayed in Nautilus, and then would access to partitions outside of the systems normally be limited?

[reed9]

A normal user should expect to see all filesystems which they have read access to. Saying their "yours" doesn't mean anything. Which user owns them, in a file permissions sense. Probably root?

Because the partitions are showing up in the computer:/// location in Nautilus, I assume they are not listed in /etc/fstab. If these are partitions you plan to access frequently, then probably the best solution is to mount them via fstab, at a custom mount point, like /Storage or /Stuff or whatever.

[DGeeez]

A normal user should expect to see all filesystems which they have read access to. Saying their "yours" doesn't mean anything. Which user owns them, in a file permissions sense. Probably root?

I suppose it must be - but, since I have never been logged in as user, it must be by default that the root takes ownership of other ext3 partitions. Isn't that kinda buggy for a system which is designed to discourage root sessions? Well, I suppose the ext3 format may have confused it - in the past there were NTFS and fat32 partitions, both which were easily accessed most of the time.

Because the partitions are showing up in the computer:/// location in Nautilus, I assume they are not listed in /etc/fstab. If these are partitions you plan to access frequently, then probably the best solution is to mount them via fstab, at a custom mount point, like /Storage or /Stuff or whatever.

Thanks.

By mount them via fstab, does that mean edit a line in the fstab file?

[reed9]

I suppose it must be - but, since I have never been logged in as user, it must be by default that the root takes ownership of other ext3 partitions. Isn't that kinda buggy for a system which is designed to discourage root sessions? Well, I suppose the ext3 format may have confused it - in the past there were NTFS and fat32 partitions, both which were easily accessed most of the time.

It's not buggy. Linux is designed as a multi-user system. You don't want regular users to willy-nilly be able to partition or format drives, especially in a networked environment. During the install process, it's quite easy to set up the partitions as needed. After the install, the system admin (in this case you) or someone with the correct sudo privileges, has the ability to set up and mount additional partitions. The ownership will by default be root, and if you want your user to have full access to it, you need to setup the ownership and permissions for that.

If you're running nautilus as root (via gksudo nautilus), you can right click on a file to change ownership and permissions. Otherwise, from the command line, user chown and chmod to change ownership and permissions of a file. (Linux sees everything as files.)

The basic syntax is

sudo chown -R USER:users /directory

where USER is your username, users is the users group, the -R is a flag to recursively change not only the directory, but all files in the directory as well.

By mount them via fstab, does that mean edit a line in the fstab file?

Yes. Here is some good info on the fstab file and how to use it. Fstab - ArchWiki